Предисловие
Я хочу рассказать о замечательном Linux-дистрибутиве Archlinux и провести вас от объяснения идеологии дистрибутива, до создания полноценной рабочей среды в нём. В этой, первой части, я на примере Ubuntu расскажу о достоинствах и недостатках системы и кратко скажу о основных понятиях дистрибутива и в принципах его работы. Остальное — в следующих частях.
Данная статья подразумевает, что у вас есть опыт в работе в Linux-системами, так как Archlinux достаточно сложный дистрибутив для новичков. Весь текст я буду сопровождать сравнениями с дистрибутивом Ubuntu. Ubuntu — потому, что самый популярный и самый в корне отличающийся от Archlinux дистрибутив. Я свято надеюсь, что это поможет проще усвоить информацию читателю.
Немного о самом дистрибутиве
Чем Archlinux отличается от Ubuntu? Ubuntu — это законченый дистрибутив с готовой рабочей средой и установленным ПО. После установки же Archlinux вы получаете голую консоль, а потом вы устанавливаете лишь то, что будет необходимо вам. Цитирую с Wiki Archlinux.
Другим руководящим принципом развития Arch Linux является свобода. Пользователям не только разрешено принимать любые решения, связанные с конфигурацией системы, но и выбирать, какой их система должна быть.
Сохраняя систему простой, Arch Linux дает пользователям свободу внесения любых изменений в систему.
Свежеустановленный Arch Linux содержит только базовые компоненты без какого-либо автоматического конфигурирования. Пользователи вольны настроить систему из консоли по собственному желанию. С самого начала процесса установки каждый компонент системы является 100% прозрачным и доступным для настройки, удаления или замены другими компонентами.
Это открывает безграничное пространство для фантазии и возможность сделать так, как хочется тебе, а не так как диктует создатель дистрибутива.
Идеология Archlinux, это целая религия, со своими фанатиками. Такие как я например, Archlinux'нутый на всю голову.
Почитайте подробнее на Wiki, чтобы понять смысл этого дистрибутива.
Ссылка 1
Ссылка 2
ПО в Archlinux
По моему мнению, ПО в большей части определят дистрибутив. Чем славятся Debian и Ubuntu? Тем, что вы можете поставить одной командой чуть-ли не любой софт из мира OpenSource, чего не скажешь о RPM-дистрибутивах. В дополнение ко всему, в Ubuntu целый вагон PPA репозиториев со свежайшим софтом. Это позволяет установить любой софт и не заниматься его сборкой из исходников и изучением устройства deb/rpm пакетов. Так же, у Ubuntu есть прекрасный пакетный менеджер apt, который является сердцем системы и позволяет рулить пакетами с таким удобством, что у Windows — пользователей слюни текут. Чем же нас удивит Arch?
Модель обновления Rolling release
Большинство людей привыкло к стандартной моделе обновлений. Сначала выпускается релиз системы будь то Windows или Ubuntu, а потом вам приходят незначительные обновления ПО с заплатками безопасности или исправлением ошибок. В Arch все немного иначе. Здесь нет понятия релиза системы в принципе. Пакеты появляются ежедневно и вы можете пользоваться самыми последними версиями сразу. Это так сказать постоянно обновляемый дистрибутив, от чего теряется необхость делать новые версии в виде установочных образов.
Pacman и AUR
У Arch есть свой бинарный пакетный менеджер и название ему Pacman. Чем он отличается от Apt в Ubuntu?
- Cкорость. Он на столько быстр, что вам покажется apt прошлым веком. Когда на старых машинах apt загибается — pacman работает со скоростью света.
- Управление. Pacman не имеет GUI, но он продуман на столько хорошо, что необходимость в интерфейсе просто отпадает. Конечно есть возможность поставить GUI, но со временем у вас отпадет необходимость им пользоваться (подробнее в следующей части).
- Зависимости. Идеология дистрибутива подразумевает простоту и элегантность во всем, от чего в Pacman зависимости сделаны так, что при установки какой либо программы будут использоваться зависимости, необходимые только для работы самой программы. Разберем это на примере архиватора. Например, установим в Ubuntu любой из GUI архиваторов и в зависимостях мы обязательно получим дополнительное ПО, такое как zip, unrar и прочее. А что, если я использую tar архивы и мне не нужны zip и rar? Pacman же установит только архиватор и выведет список рекомендуемых зависимостей включая все возможные форматы архивов. В Ubuntu такой возможности нет, даже с использованием --no-recommends-install
Pacman кстати содержит не так уж много пакетов и далеко не всегда можно установить то, что есть стандарных репозиториях Ubuntu, но есть такая прекрасная вещь, как AUR.
Итак, что же такое AUR? AUR (Arch User Repository) — поддерживаемый энтузиастами репозиторий, содержащий, скрипты для автоматической сборки приложений из исходных кодов. Каждый имеет право добавить понравившееся приложение в репозиторий AUR. Если же пакет в AUR набирает определенное количество голосов, то он попадает в оффициальный репозиторий. AUR — это место, где можно найти практически все. Пользователи постоянное добавляют огромное количество новых пакетов и обновляют старые, что компенсирует скудный оффициальный репозиторий.
Конфигурация дистрибутива
Все, что есть в Archlinux — можно настроить. Любые настройки дистрибутива производятся через конфигурационные файлы, вместо GUI-программ в Ubuntu. И снова, у нас появляется возможность настроить все именно так, как мы хотим без прибегания к GUI. Зачем для настройки системы использовать малофункциональный GUI, когда все можно сделать через конфиги? (камень в огород Ubuntu Tweaker и прочей мути). С другой стороны, это крайне тяжело делать начинающим пользователям, но это ведь не про нас.
Поиск информации
Пользователи Ubuntu привыкли искать информацию в Google попадая на форумы где рекомендуют сделать
perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see' В Archlinux все намного проще и удобнее. У Archlinux есть собственная Wiki, где можно узнать 95% информации по системе и чуть-ли не всему ПО в ней. Остальные 5% информации выпадают в первых поисковых строках с оффициального форума. Правда есть один минус. Многие статьи на русском в Wiki сильно устарели и не соответствуют текущему ПО, поэтому рекомендую сразу открывать английскую версию и смотреть там. Хотя, кто знает, возможно ты, новый арчевод поможешь актуализировать документацию для Archlinux.
Заключение
Arch Linux представляет собой конструктор, из которого можно собрать хоть простую систему для слабых машин, так и систему наполненную ПО для работы на мощных машинах чем. Arch требует времени на первоначальное освоение дистрибутива, но это компенсируется тем, что он гораздо лучше поддаётся настройке, чем например Ubuntu.
В отличие от так называемых user-friendly дистрибутивов настройка довольно сложна и терниста. Чтобы установить систему, как минимум придётся перед установкой прочитать Beginners Guide из wiki. Так как понятие, как стандартная установка в Ubuntu, отсутствует. Для установки придётся самому принимать много решений и прописывать множество параметров. Если всё будет сделано правильно, вы получите систему без ненужного мусора.
Цитата с Lurkmore:
Несмотря на внешнюю сложность, установка и настройка не настолько уж и сложна. Достаточно иметь усидчивость, четкое понимание и осознавание своих действий и внимательность (а ещё очень тщательно изучать ArchWiki). То есть, если говорить проще, не торопиться. Документация описывает все очень подробно, с примерами, что позволяет довольно быстро начать понимать, что вообще происходит и зачем это нужно.
На этом пока все. В следующий раз мы установим систему с нуля и до рабочего окружения. Спасибо.
Комментарии (174)
skobkin
27.10.2015 09:14+14Философия дистрибутива не до конца раскрыта (тут можно провести параллели с философией Gentoo). И всякий маркетинговый буллшит типа «безграничное пространство для фантазии» бросается в глаза. А в целом статья скорее полезна, т.к. пропагандирует более гибкие дистрибутивы типа Arch и Gentoo.
Кстати, арчевики — действительно очень полезный ресурс. Зачастую там можно найти много полезной информации по настройке всего и вся.
k12th
27.10.2015 11:33+5Простите, оффтопик: задумался, что за юнит такой — арчевик и чем он так полезен.
fshp
27.10.2015 15:56Причём не только арчеводам их вики полезна.
Гентушная вики последнее время возрождается — современная вёрстка, обновлённые статьи. Года 4 назад она казалась совсем мёртвой.
Meklon
27.10.2015 22:12+1Я кубунтоид, но арчевики читаю с удовольствием прекрасные мануалы с примерами.
fshp
27.10.2015 22:19+1О чём и говорю. А с учётом того, что подновляющее большинство дистрибутивов используют systemd+udev, то большинство примеров можно даже без модификаций использовать для той же кубунты.
aik
27.10.2015 09:24+13Пакеты появляются ежедневно и вы можете пользоваться самыми последними версиями сразу.
Думаю, что анстейбл-версии есть у всех дистрибутивов.
Когда на старых машинах apt загибается — pacman работает со скоростью света.
И за счет чего он это делает? Самое тяжелое для процессора при установке софта из деб-пакетов — это распаковка. Что, пакеты в арче хранятся незапакованными?
Pacman не имеет GUI, но он продуман на столько хорошо, что необходимость в интерфейсе просто отпадает. Конечно есть возможность поставить GUI
Так вы определитесь, есть у вас GUI или нету. Это во-первых.
У самого apt, в общем-то, GUI тоже нету. Это во-вторых.
установим в Ubuntu любой из GUI архиваторов и в зависимостях мы обязательно получим дополнительное ПО, такое как zip, unrar и прочее. А что, если я использую tar архивы и мне не нужны zip и rar? Pacman же установит только архиватор
Откуда при установке графической оболочки для архиваторов, арч будет знать, что вам нужна только поддержка tar? Вы это указываете отдельной опцией?
Итак, что же такое AUR? AUR (Arch User Repository) — поддерживаемый интузиастами репозиторий, содержащий, скрипты для автоматической сборки приложений из исходных кодов.
Интузиастами? Ну и вообще, чем-то мне это PPA напоминает…
Зачем для настройки системы использовать малофункциональный GUI, когда все можно сделать через конфиги?
Потому что в GUI проще настроить контроль ввода. А в конфигах вы поставите лишний пробел, а потом будете его полгода искать. Так что GUI — это хорошо. Для начинающего. А для что-то знающего конфиги никто не отменял даже в убунте. vim в зубы — и вперёд, в /etc
Пользователи Ubuntu привыкли искать информацию в Google попадая на форумы где рекомендуют сделать perl -e '
Это уже смотря как вы запрос в гугл составите.
Arch Linux представляет собой конструктор, из которого можно собрать хоть простую систему для слабых машин, так и систему наполненную ПО для работы на мощных машинах чем.
И? Почему именно арч? Почему не дебиан, например? Или генту, на худой конец?
Тема не раскрыта, в общем.
k3NGuru
27.10.2015 10:13а Synaptic разве не GUI для apt?
aik
27.10.2015 10:18+4А какой-нибудь AppSet или wakka разве не GUI для pacman?
k3NGuru
27.10.2015 10:21У самого apt, в общем-то, GUI тоже нету. Это во-вторых.
Я про данное высказывание. Про Pacman я не вкурсе, так как в основном Debian/RHEL дистры используюaik
27.10.2015 10:42+7Синаптик — это такой же гуй, как и пакмэновские.
А изначальный интерфейс у apt вполне себе консольный и в убунте он никуда не делся. Я этот самый синаптик только на картинках видел. GUI убунты, впрочем, тоже. :) Она стоит на паре серверов и в консоли ничем не отличается от дебиана.
serf
27.10.2015 11:49+2Интузиастами? Ну и вообще, чем-то мне это PPA напоминает…
Это как сказать, PPA разрознены против единого AUR.
avalak
27.10.2015 14:06-7Позвольте полюбопытствовать, а что, собственно, хорошего в «едином AUR»?
В ppa у каждого своя изолированная песочница, а AUR это просто общая помойка рецептов разной степени паршивости.fshp
27.10.2015 15:59+2Если ментейнер забросил обновлять пакет в AUR, то любой желающий может получить права на него и продолжить обновлять.
Если умер ppa, то это навсегда.avalak
27.10.2015 16:24-4В общем-то не вижу здесь ничего ужасного.
Прискорбно, конечно, когда загибаются хорошие ppa, но переключиться на другой (или даже свой поднять) не проблема.
А вот если майнтейнер забросил (или просто недооформил) пакет, то придётся его искать, узнавать планирует ли он его поддерживать, считаться с его мнением, объяснять почему нужно сделать так, а не иначе.
Нельзя так просто взять и разместить в AUR дубликат, а обычно очень хочется и чтоб пакет был оформлен согласно стандартам и чтоб работал нормально (стабильная версия 2.0, а не ololo-git которая может и не собраться).
evilsprut
27.10.2015 16:11Спасибо за то, что уделили внимание, в следущий раз учту все замечания и расскажу про всё более подробно.
fshp
27.10.2015 22:26+4Самое долгое в установке deb-пакетов это не распаковка, а обработка триггеров и скрипты настройки.
aik
27.10.2015 22:28Я про тяжелое для процессора сказал. Скрипты настройки — тут больше дисковая активность. Или в арче ничего такого нет, скачал, распаковал и бросил как есть, а дальше пусть юзер сам всё настраивает?
fshp
27.10.2015 22:31Да. Pacman проверяет лишь конфликты файлов.
aik
27.10.2015 22:58То есть сразу после установки программы к использованию непригодны, так? Если ставишь какой-нибудь пхпмайадмин, то придется руками его донастраивать, чтобы запустить?
fshp
27.10.2015 23:03Минимальный конфиг идёт в поставке. Так что в большинстве случаев ничего не нужно править.
aik
27.10.2015 23:26Я не так просто про phpmyadmin сказал.
Ему же надо завести базу, указать имя и пароль для доступа, прописать в конфигах вебсервера путь к папке с файлами…fshp
27.10.2015 23:32Откуда же dpkg знает логин/пароль и имя базы?
olegchir
28.10.2015 00:22пост-инсталл скрипт может спросить и это, и вообще что угодно
олсо есть вот такая фиговина: «sudo tasksel install lamp-server» (внимание на отсутствие апта или дпкг в команде), она тоже может что-нибудь спросить
fshp
28.10.2015 00:27Спросит и запишет это в конфиг. Какое принципиальное отличие от ручной правки?
Arch рассчитан на опытных пользователей. Поэтому ручная правка конфигов предпочтительнее всяких UI.
Я не спорю, dpkg-reconfigure замечательная штука. Но у Arch другая идеология.olegchir
28.10.2015 00:36-1криворукие разработчики могут сделать не KISS конфиг в своем приложении (или группе приложений), в котором без поллитры не разберешься. Или вообще не разберешься. Например, установка почтового сервера обычно занимает кучу времени, хотя бы тупо на набивку конфигов, понаставить вот эти 100500 серверов и потом склеить их все изолентой. Шаблон конфига не поможет, потому что непонятно как именно ты собираешься склеивать кусочки инфраструктуры. В принципе неплохо, если кто-то всё это говнецо пред-сгенерит, кто-нибудь типа tasksel'а.
имхо, вся эта идеалогия хороша, когда сам софт уважает KISS, уважает UNIX-way, итп. Но не весь софт такой. Некоторый софт написан закоренелыми виндузятниками, например, и даже конфиги там в SQLite которую надо править через специальный гуй на питоне. Кроме почтового сервера, еще канонические примеры — группы серверов на основе Java Enterprise стека или Ruby стека (тоже Enterprise в джавовском смысле). Чтобы настроить элементарные вещи типа пароля в базе данных нужно шарить в Java и Ruby с кучей технологий. Обычному человеку это точно не надо, ему бы установить какой-нибудь Гитлаб, чтобы он просто взял и запустился, без изучения как править кукбуки для Chef (или на чем там инсталлятор написан, уже забыл)
aik
28.10.2015 00:38Спросит и запишет это в конфиг. Какое принципиальное отличие от ручной правки?
Экономия времени. Пусть оно ставится на пару-тройку минут дольше. Но зато экономит полчаса ручной правки конфигов.
olegchir
28.10.2015 00:19+2скрипты можно бы и написать, но никто так не делает
устанавливаешь прогу, и потом идешь сам всё настраивать в конфиге
что именно настраивать — написано на арчевики
в функционировании системы не должно быть магии. Система должна быть умопостигаема. Это основа KISS.
если мы устроили post-install hell, то в конце концов это приводит к системе типа Windows, когда прога при установке не копирует файлы, а «инсталлируется». Что она там делает при «инсталляции» — тёмная электрическая фигня, которую уже сами создатели «инсталляторов» не умопостигают. На Шиндовсе доходит до смешного, что например человек установил базу данных, а где в ней пароль хранится и как его поменять — он не знает (и некоторое время может даже жить с этим в неведении)
так вот всего этого говна нам не надобно
более прямой ответ на ваш вопрос про PHPMyAdmin находится вот здесь: wiki.archlinux.org/index.php/PhpMyAdmin
эту статью нужно прочитать перед установкойaik
28.10.2015 00:41И какая причина делать всё это руками, а не доверить скрипту установки?
olegchir
28.10.2015 00:52Если поставил 1 раз и забыл навсегда — наверное, никакая
Но у меня паттерн использования другой. Есть некая база (ведро, тулчейн, итп), куда я не лезу и «поставил и забил. Всё остальное, что поставлено руками, постоянно часто-часто-часто конфигуряется. Мне нужно знать где находятся все активные (влияющие на работу) файлы конфигурации, знать и понимать все строчки в них, знать как выполнять типичные операции над группой конфигов, итп.
В таком паттерне использования, возникает куча вопросов к разным установщикам типа „а точно ли когда скрипт установки спрашивал юзернейм, он поправил только строчку user_name=zxc, или еще поменял роли?“. „а не положил ли он файл конфига не туда, куда следует?“. „а оно стартует через системд или через инит?“ итд итп.
Всё это решается, например через декларативно описанные кукбуки. Чтобы перед установкой можно было открыть и прочитать, что именно будет произведено „скриптом установки“, поправить всё это, итп. Инсталляторы можно писать на каком-нибудь пайтоне, чтобы не ломать мозг об баш и перл. Итп
Но в простых случаях не совсем понятно, зачем оно мне надо, нагружать мозг вопросами о том как работает установщик, если его можно просто не использовать, а сделать вручную конфиг прямо из шаблона конфига.
bottom line, система должна быть умопостигаемой. Чтобы можно было удержать в голове все действительно занчимые шестеренки. Чтобы никакой магии. Система делает то, что я придумал для нее делать, а не наоборот. Чтобы это было возможно, вся схема работы должна быть изложена в ясном, простом для понимания и запоминания виде. Скрипт установки — это НЕ простой, НЕ ясный, и совершенно НЕ запоминаемый способ описания структуры системы.aik
28.10.2015 01:25Не слишком представляю, зачем может понадобиться такое удовольствие для всего установленного софта.
А для отдельных программ можно и свои пакеты собрать, со своими пост-инсталл скриптами.
witdex
01.11.2015 02:31+1Так вы ведь говорите про phpmyadmin, а не про весь софт. Это принципиальная разница. А что такое phpmyadmin? Это ведь не статический бинарник с пару конфигами, где можно спросить user pass и просто скопировать все в нужные папки(в данном случае делает установщик). phpmyadmin это ведь целый стек. Вы предлагаете убунту вэй где сделал apt-get phpmyadmin и поставился целый стек LAMP. А как он работает? — как WAMP. Что мы имеем? — Windows вэй. И сразу как у разработчика появляется куча вопросов у меня. Начиная версиями софта, заканчивая тем что мне не нужен apache, а нужен nginx. Нужен не mod_php, а php5-fpm. Нужна не mysql, а mariadb. Ну и толку мне от того что я сделал apt-get phpmyadmin?
Так вот KISS в том чтобы поставить все по порядку и осознать, потому что если вдруг все перестанет работать ты точно будешь знать где перестало и на крайняк можно пакет переустановить и все. А если человек не может поставить php, то phpmyadmin ему точно не нужен. Либо его уровень как разработчика Windows + Denwer.
Арч учит. Если тебе нужен Gnome или Xfce поставь x-сервер, в большинстве(!!!) случаев тебе абсолютно ничего не придется конфигурировать. Философия Арча избежать громоздких утилит типа ubuntu-tweak, но это не значит что он заставляет тебя поднимать сеть с нуля в конфигах или писать конфиги чтоб мышь заработала. Для всего есть утилиты/скрипты — 99.9%. Но каждая отвечает за свои задачи.
Вообще установка арча, занимает минут 30 неопытным пользователем следуя Beginners' guide и самое сложное это наверно разметка диска и решить какой загрузчик ОС поставить, остальное это установка пакетов и минимальная правка конфигов — типа убрать комментарий в конфиге какой язык выбрать и т.п. Ну с этим даже секретарша разберется.
Но на самом деле пользователей пугает не настройка, а принятие решений: — А какой менеджер рабочего стола мне поставить KDE, GNOME, XFCE...? Что такое оконный менеджер вообще?.. — Ответ: Да поставь их три, запусти по одному и выберешь.
Другое дело когда выбора нет либо — unity и все. Хочешь другой ставь Kubuntu, другую ОС вместо того чтобы просто пакет доставить а старый удалить. С ума сойти. О какой гибкости системы мы говорим? Мы что на Виндоус. Или мы говорим о простоте? Если о простоте тогда, есть арч-вики, там все так разжовано на любые темы, что убунта с кучами форумов и блогов отдыхает.
Арч как раз учит решать проблемы просто. Т.е. есть ваша задача — 1. нужен phpmyadmin 2. но не на долго грубо говоря.
Этот KISS я вижу так:
1.1. sudo pacman -S php mariadb # пароль для root в БД меня спросят
1.2. на сайте phpmyadmin.net качаем архив, распаковываем куда хотим, допустим /home/max/phpmyadmin
1.3. sudo systemctl start mysqld && cd /home/max/phpmyadmin && php -S localhost:8080 && firefox localhost:8080
# например можно создать alias phpmyadmin='sudo systemctl start mysqld && cd /home/max/phpmyadmin && php -S localhost:8080 && firefox localhost:8080' и потом просто в консоли набирать phpmyadmin
2.1. логинимся -> делаем что то с БД -> экспортируем БД
2.1. sudo pacman -Rnsc php mariadb && rm -rf /home/max/phpmyadmin
Финиш. Проблема исчерпана. Если же работа элементарная в консоли это тяжело, тогда гоу на виндовс с кучей GUI утилит. Становится PHP Developer for Windows Denwer only. И ставить в резюме напротив графы Unix минус. Только кто воспримет такого разработчика серьезно, если он себе окружение даже подговить не может а юзает Денвер.aik
01.11.2015 22:24phpmyadmin — просто пример.
мне не нужен apache, а нужен nginx. Нужен не mod_php, а php5-fpm. Нужна не mysql, а mariadb.
Ну так поставьте то, что вам надо до установки phpmyadmin, а не вместе с ним. Вам же сперва предлагают список на утверждение. Не нравится предлагаемое — ставьте своё. Нужно просто уметь пользоваться инструментом.
Ну и толку мне от того что я сделал apt-get phpmyadmin?
Обновляться будет через репозиторий, не придется скачивать каждый раз ручками архив от разработчика.
если человек не может поставить php, то phpmyadmin ему точно не нужен.
А зачем ставить php отдельно, если её по зависимостям всё равно вытянет? Я на свежей системе как раз обычно phpmyadmin ставлю, чтобы он всё нужное для работы php и mysql притащил.
Арч учит
Чему он такому учит, чему не могут научить генту или дебиан? Или вообще фря?
Или мы говорим о простоте?
О простоте чего именно мы говорим?
Арч как раз учит решать проблемы просто
Угу. Только сперва их создает.
Если же работа элементарная в консоли это тяжело
Не тяжело. Просто не нужно. Зачем вводить десяток команд, ходить на какой-то сайт, что-то скачивать и распаковывать, если можно всё сделать одной командой?
кто воспримет такого разработчика серьезно, если он себе окружение даже подговить не может
Вообще-то, готовить окружение — не забота разработчика. Для этого админы есть.
olegchir
28.10.2015 00:11+4> Думаю, что анстейбл-версии есть у всех дистрибутивов.
у Арча такая система считается стабильной и поддерживается соответствующе
а у Дебиана если что-то сломалось в анстейбле, мантейнеры на это просто забивают, «анстейбл же, фигли, жрите что дают»
наверное, даже testing у Арча держится в более-менее приличном состоянии. Что-нибудь временами разваливается в хлам, но это горе-горе, и это будут чинить
можно сказать, тут отличие именно в идеалах, в идеологии. Система со свежими пакетами НЕ означает, что на нее можно забить кому-либо
> Pacman же установит только архиватор
> Откуда при установке графической оболочки для архиваторов, арч будет знать, что вам нужна только поддержка tar? Вы это указываете отдельной опцией?
Помойму «Pacman же установит только архиватор» — вот это как раз было неправда. В общем случае, если софтина ванильная, ее надо собирать в максимальной комплектации, чтобы не нужно было писать никаких «выпиливающих» патчей. Писать патчи — это не тру, софт должен быть как у разработчика.
Имхо, чуваки, которые «zip и rar мне не нужны» маются фигней, в 2015 году, когда у всех гигбайты RAM и терабайты жестких дисков, все это уже не имеет никакого значения. Только головная боль.
> Ну и вообще, чем-то мне это PPA напоминает…
PPA не централизованный, и с ними надо МНОГО геморроиться. Подключать, поддерживать между переходами между релизами (а у арча релизов нету), итп
У меня сейчас на рабочей машине подключено около 30 PPA, и каждый выход новой версии Ubuntu (я сижу на бетах) начинается хардкорный гемор по обновлению всей этой фигни
А AUR — это что-то типа AppStore или GooglePlay. Такое простое хомяковое решение, машина «сделай мне зашибись». Пишешь что хочешь, давишь кнопку, дальше не твое дело.
Так же как в сторах, там есть и проповедуется система комментариев под пакетами (в отличие от ланчпада). Если что с пакетом не так, в каментах сразу образуется лютый срач.
Мне не хочется думать над PPA, я хочу хомячковое решение, пыщ-пыщ и продакшен
> Потому что в GUI проще настроить контроль ввода. А в конфигах вы поставите лишний пробел, а потом будете его полгода искать.
Ваш софт — говно. Нормальный софт при релоаде конфига выполняет точно такую же валидацию как и гуй, и человечьим голосом пишет, в какой строчке конфига ошибка, и на что ее поправить
С точки зрения разработчика это даже удобней. В гуе (особенно ужасном gtk) нужно заморочиться с выводом валидаторов на формочку. А в консоли таких проблем нету, что видим то и пишем, тупо через printf, или System.out.println, или на каком языке вы там пишете, тупо в std
> Пользователи Ubuntu привыкли искать информацию в Google попадая на форумы где рекомендуют сделать perl -e '
> Это уже смотря как вы запрос в гугл составите.
По арчу тоже 100500 таких советовaik
28.10.2015 00:49у Арча такая система считается стабильной и поддерживается соответствующе
А рассказы в соседних комментах вида «я обновился и всё развалилось»?
а у Дебиана если что-то сломалось в анстейбле, мантейнеры на это просто забивают, «анстейбл же, фигли, жрите что дают»
Не наблюдал такого. Чинят. Хотя и небыстро, если баг неприоритетный. Но я анстейблом и не пользуюсь практически. Стейбл — наше всё. :)
У меня сейчас на рабочей машине подключено около 30 PPA
У меня сторонних репозиториев два или три. Точно i2p, а что еще — даже и не вспомню сейчас. Редко обновляюсь без серьезной на то причины. Регулярно только секьюрити-апдейты. Так что страдания с левыми репозиториями как-то мимо меня. :)
Ваш софт — говно. Нормальный софт при релоаде конфига выполняет точно такую же валидацию как и гуй, и человечьим голосом пишет, в какой строчке конфига ошибка, и на что ее поправить
Нихрена. Валидация конфига идёт только на правильный синтаксис. Но вот написать синтаксически правильную фигню эта проверка обычно не мешает.olegchir
28.10.2015 00:59> А рассказы в соседних комментах вида «я обновился и всё развалилось»?
скорей всего, значит, вообще у всех развалилось. Обновляются все, обновляют всё, и часто. По сути, получается некий continuous integration с глобальными тестерами в виде пользователей и очень коротким релизным циклом. Поломка у тыщи человек разом — это мега важно, это тут же поправят и напишут в новостях способы решения. Конечно перед обновлением нужно читать новости.
> Нихрена. Валидация конфига идёт только на правильный синтаксис. Но вот написать синтаксически правильную фигню эта проверка обычно не мешает.
чот не понял, а в чем тут разница с графическим гуем-то? Графический гуй тоже можно написать только под правильный синтаксис. Н-р в веб-приложухе в HTML валидировать поля по маске каким-нибудь jquery masked input, как делает каждый второй альтернативно одаренный. Вопрос в том, хочет ли девелопер сделать проверку семантики или нет, а какой уровень презентации используется (нативный гуй, веб, конфиг, конфиг в бд, еще как-то) — ваще поровную. Или я чего-то не понимаю, поясните?
grossws
28.10.2015 04:25А рассказы в соседних комментах вида «я обновился и всё развалилось»?
За последние лет 5 на арче разваливалось крайне редко. Основные варианты (в порядке уменьшения встечаемости):
— обновился один пакет, а зависимый от него ещё отсутствует на используемом зеркале (лечится откатом или повторной установкой, когда зеркало синхронизируется);
— обновился не заглянув в новости, где писали, что надо сделать перед/при обновлении;
— проблемы в upstream, которые не отловили в testing (из последнего, на что нарвался — glib2 2.46.0, приводивший к падению jre);
— собственные кривые руки при экспериментах.
А вот прекрасный развал ubuntu server где-то в районе 9-10 наблюдал при штатном apt-get upgrade.
rudenkovk
28.10.2015 07:00-1Ровно описаны те проблемы, которые не позволят использовать арч, для чего-то более серьезного, чем разработка под LAMP. Я уже писал выше: первая заповедь, стабильная система.
Кстати про убунту согласен, разваливалась, как и дебиан. Лет 5 назад. У меня проды по 20-30 тыс машин не разваливаются :)grossws
28.10.2015 14:43-1Вы таки уже который раз пытаетесь оскорбить всех, кто не разрабатывает на языках с компиляцией в нативный код хоста. Как то, интерпретируемые языки, jvm, .net, embedded и т. д.
Если вам лично (или в вашей области) разработчику необходимо иметь окружение, совпадающее с боевым, то пожалуйста, ваше право.
На деле, оно обычно не совсем так. Например, на рабочей станции разработчика, скорее всего, будут xorg, какая-нибудь DE, куча библиотек связанных со звуком, графикой и т. п., которые не нужны (и будут по умолчанию отсутствовать) на сервере. Так что CI с reproducable builds никто не отменял.
При динамической загрузке модулей (например, на основе наличия определенной библиотеки) вполне можно оказаться в ситуации, что на станции разработчика de facto отлаживалась совсем другая конфигурация. И здравствуй, remote debug, как в embedded.rudenkovk
28.10.2015 15:04Таки я ни разу никого не пытался оскорбить. И даже не гажу в вашу песочницу.
Я везде четко проводил одну и ту же простую мысль, что разработка под LAMP это одно, а разработка требующая УПРАВЛЕНИЯ ВЕРСИЯМИ СИСТЕМНЫХ БИБЛИОТЕК (или если шире окружения выполнения), это другое. И точно так же, это может касаться и jvm, и embedded и прочего. И как следствие, то, что arch с его подходом не готов к использованию в подобного класса проектах.
Если уж пойти еще дальше, я знаком с проектами, завязанными на LAMP-стек, где люди дописывают свои форки/либы для проекта — и это уже требует разборки с системными либами и линковкой.
И по отношению к моим словам, которые Вас так возмутили: думаю для вашего кошелька будет вполне понятна разница: между гарантированным LTS и хаосом (это не оскорбление, а объяснение бардака и сопровождения) поддерживаемой сообществом. Ибо консистентный и поддерживаемый В ЦЕЛОМ репозитарий требует внимания, труда и вложений. В отличии от…
grossws
28.10.2015 15:56-1для чего-то более серьезного, чем разработка под LAMP
разработка под LAMP это одно, а разработка требующая УПРАВЛЕНИЯ ВЕРСИЯМИ СИСТЕМНЫХ БИБЛИОТЕК (или если шире окружения выполнения), это другое
Вот эта ложная дихотомия и является глупостью. LAMP/LNMP — лишь один из сегментов, не требующих управления версиями системных библиотек. Считать, что серьезны только те задачи, которые этого требуют, а остальные несерьезны, как массовая разработка под LAMP — несколько странно.
Кроме того, всякие вещи типа LD_LIBRARY_PATH или статической линковки никто не отменял. Вполне себе подход к управлению зависимостями, отвязывающий от подавляющего количества системных библиотек.
гарантированным LTS и хаосом (это не оскорбление, а объяснение бардака и сопровождения) поддерживаемой сообществом. Ибо консистентный и поддерживаемый В ЦЕЛОМ репозитарий требует внимания, труда и вложений. В отличии от…
От вас ускакал розовый единорог. Гарантированный LTS — это либо утопия (в случае debian, ubuntu lts), либо ощутимые деньги (rhel). И то, если не используете сторонних библиотек/систем с иными гарантиями по поддержке, нежели основной дистрибутив. RR и хаос — существенно разные вещи, и первый требует усилий на поддержку. Тот же testing в арче не просто так существует.
Лично у меня на арче проблем количество «проблем» с обновлением не больше, чем на боевых серверах под centos 6 и 7. Ручное вмешательство иногда нужно (например, при переходе с initscripts на systemd), но это исключение. Аналогом такого ручного вмешательства в обычных дистрибутивах является обновление major версии. Та же ubuntu у меня в такие моменты ломалась несколько раз. Centos просто не рекомендует обновление на следующий major, кроме как через бэкап и чистую установку.
Если вам кажется, что на арче нельзя заниматься серьезной разработкой — это ваши личные трудности. Я разрабатываю и проблем не испытываю. Java/scala (с jni и jna), python (с нативными модулями), ruby (с нативными модулями) прекрасно переносится на stage и production.rudenkovk
28.10.2015 16:21-1Вы очень не внимательны к тому, что я писал. Я нигде не говорил о несерьезности задач для LAMP, я указал только то, что для данного стека управление версиями/средой не является серьезной проблемой, и соответсвенно не важно на чем вы это реализуете. Да хоть в cygwin, и пишите в лексиконе. Я прямо писал о вопросе ПОДДЕРЖКИ, как и прода, так и станций разработки, особенно если есть тонкости. И как подмножество данного процесса — поддержка среды сборки и выполнения, не зависимо от используемых для разработки технологий. И уж очень жаль, что данный подход вы сочли для себя оскорблением.
Я рассматриваю вопрос применения дистрибутива не с позиции, что у меня есть N разработчиков, которые себе сами все админят, да и еще и прод настраивают. А с позиции того, что у вас есть потребность в стабильности и сокращении расходов.
Вы мне хотите доказать, что арч крут — да пожалуйста, крут. Но только я не слышал не об одном более менее серьезном внедрении арча. Вы сами, на большой толстый прод готовы его поставить? А поддерживать? А уйти с проекта и передать его новому человеку? Подумайте и ответьте, себе, без бравады.grossws
28.10.2015 16:42-1При чём здесь арч на production серверах? Мы говорили про арч на рабочей станции разработчика, где, как вы утверждали, он не применим для «чего-то более серьезного, чем разработка под LAMP».
Повторюсь. Если вам на рабочих станциях разработчиков нужна среда разработки, содержащая надмножество библиотек production-среды, то никто не мешает вам её иметь, используя те же дистрибутивы, что и в production. Правда, всё хорошо, пока все боевые сервера используют один и тот же дистрибутив одинаковой версии. Иначе, смотрите рис. 1.
Среда для тестирования (CI) должна быть максимально приближена к боевой и давать reproducable builds, иначе смысла от неё примерно ноль. Иного я не утверждал.
Далеко не все «серьезные», как вы выразились, задачи требуют такой конвергентности среды.rudenkovk
28.10.2015 16:48-1Думаю мне нечего вам больше сказать. Я свою позицию, и ее причины, тут разжевал уже дважды.
Вы думаете критериями одного человека/маленькой команды (пока у меня нет оснований думать иначе), я думаю критериями более крупной команды, продакшена, зоопарка сред, методик CI/CD и поддержки этого хозяйства. Ключевые слова: ПОДДЕРЖКА и ЗООПАРК.
PS И я не менеджер от ИТ, и не сисадмин.olegchir
31.10.2015 22:31+1Допустим, обновилась либа и что-то в софтине сломалось — это тут же покажут юнит-тесты на дженкинсе, автоматическеие интеграционные тесты, вас засыпят письмами тестировщики итд итп. Если это какой-то некритичный баг, дошедший до продакшена, завалят письмами пользователи. Сразу после этого кем-то будет инициировано создание тикета, на который тут же отреагируют программисты и подточат этот острый угол
Насчет поддержки все просто — в команде разработчиков софта, который пишется для этого сервера, есть выделенный программист (или девопс), который этот конкретный проект и поддерживает. Возможно, толпа таких людей. Все вопросы к ним. Они свой собственный продукт, для которого код пишут, знают вдоль и поперек.
Если это неленивые люди, которые шарят в своей системе как боги — все отлично (и неважно, что у них там за система! Хоть Арч, хоть Убунту). Если там ленивые раздолбаи «поставили и САМО ПО СЕБЕ работает 10 лет подряд, голавное не трогать» — увольняем их и нанимаем нормальных людей. Все просто.
rudenkovk
28.10.2015 16:58PPS По сути тут вы сказали ровно то, что я пытался донести. И с одной оговоркой: вы свою среду разработки поддерживаете САМИ (опять же, если я вас верно понял). Я поддерживаю ЗООПАРК сред разработки, где люди задают странные вопросы начинающиеся с «а почему работает там, но не тут» и требующие ПОДДЕРЖИВАТЬ их среду разработки. И тут встает вопрос УНИФИКАЦИИ.
В следствии того, как осуществляется поддержка арча, он не может быть УНИФИЦИРОВАН на некоторое количество машин без существенных трудозатрат, тем более если возникает вопрос ПРОСТОГО и ГИБКОГО управления зависимостями в соотвествии с продом. В отличии от «розового единорога» LTS.grossws
28.10.2015 17:50вы свою среду разработки поддерживаете САМИ (опять же, если я вас верно понял)
Именно. И пока нет организационных требований на унификацию среды разработки (а не тестирования с CI), поддержки среды разработки со стороны отдельного оргподразделения и тому подобных проблем, использования arch или gentoo разработчиком на своей рабочей станции — вполне допустимая практика. В том числе, для разработки приложений отличных от веб-приложений на lamp или аналогичных стеках на php, python, ruby и js.
В следствии того, как осуществляется поддержка арча, он не может быть УНИФИЦИРОВАН на некоторое количество машин без существенных трудозатрат, тем более если возникает вопрос ПРОСТОГО и ГИБКОГО управления зависимостями в соотвествии с продом.
Как можно было догадаться раньше, дистрибутив-конструктор и не должен это обеспечивать. Нужен стабильный дистрибутив — берите rhel/ubuntu lts/debian stable/whatever, кто вам мешает? Но обращать импликацию «если используется стабильный дистрибутив, то нет проблем с системными зависимостями» — не следует, это логическая ошибка.rudenkovk
29.10.2015 09:51Бинго! Мы начали говорить на, почти, одном языке. :)
К вопросу о дистрибутиве конструкторе.
Еще лет 8 назад я делал прод решения на Gentoo, которые до сих пор работают. На всякий случай: БОЛЬШИЕ ТОЛСТЫЕ ПРОДЫ (> 500 серверов). Соответсвенно под это делались и окружения на рабочих станциях. За счет того, что джента КОНСТРУКТОР, и системы оверлеев дженты, была настроена гибкая возможность по обновлению систем и контролю версий библиотек (и окружения в целом). Внедрение туда систем типа puppet/ansible упростило процесс сопровождения. Безусловно, это потребовало больших затрат на начальную настройку, но дешевле, чем rhel, в финансовом выражении (ну а убунты тогда не было, вернее не была она готова к проду, а дебиан не брали за излишнюю консервативность и убогий pbuilder). А в дальнейшем затраты на сопровождение сопоставимы. Вот системам уже ~6-8 лет, а ни одного epic не было, хотя сменилось уже не одно поколение администраторов и девопсов.
На сколько я понял то, что обсуждалось тут, касательно арча, на нем сделать такое не возможно (читать как не вообще, а как с адекватными трудозатратами), и проблема кроется именно в поддержке репозитория.
Но обращать импликацию «если используется стабильный дистрибутив, то нет проблем с системными зависимостями» — не следует, это логическая ошибка.
Мое утверждение тут было не более чем: если вы берете стабильный дистрибутив, то априори, у вас будет меньше проблем с контролем версий/зависимостей. И как следстве мой вывод: арч не production ready даже для командной работы, если человек не поддерживает свою среду разработки сам (о прогнозировании трудозатрат я писал). С моей точки зрения это логично, и по умолчанию, можно не озвучивать дальше.
olegchir
31.10.2015 22:05Кроме той идеалогии, которую вы тут в комментах проповедуете, есть еще одна. Она формулируется так:
1) Есть текущая версия софтины 2) и есть устаревшая
«Управление версиями системных библиотек» состоит в том, чтобы взять устаревшую версию и обновить до текущей. Всё.
Весь софт соответственно должен постоянно тестироваться и рефакториться вместе с апгрейдом версий библиотек.
Данный подход исповедует множество SaaS решений, в том числе Arch и Windows 10 (по крайней мере в Windows есть курс на данный подход), Firefox, Chromium итп.
Дистрибутив есть не просто набор софта, а конкретный сервис постоянной пере-интеграции системы.
Усилия по проведению непрерывной стабилизации «текущей» версии — ОГРОМНЫ.
(Настолько огромны, что без специальной дисциплины их не достичь. Слава богу, у нас есть эта дисциплина).
Без специальных методик — намного больше, чем создание фиксированной «стабильной» версии системы. LTS ты интегрируешь, предположим, один раз в год, а с rolling release нужно пердолиться каждый божий день.
В общем, это не хаос, это особый уровень порядка, требующий специфической активности.
Если интересно больше, разберитесь с тем, как создается Firefox или что-то похожее, о чем есть публичная информация.rudenkovk
01.11.2015 21:22-1И снова, спасибо Кэп! :) (см мой постскриптум в предыдущем моем ответе вам.)
Тут есть одно маленькое НО, вернее два: Legacy и Enterprise, в очень широком понимании. И это я то же озвучивал, кажется.
Причем Legacy и его поддержка, даже в динамичной команде с непрерывным циклом релизов и, даже (!), наличием программистов на вынос этого legacy и его зависимостей может занять ГОДЫ, даже в LAMP проекте, где все это уже не так важно… по идее.
То что вы описываете прекрасно, и утопично в своей прелести. В реальном мире (если угодно: в реальном бизнес мире). И это вы то же верно озвучиваете.
И поэтому, снова, спасибо Кэп! :)
grossws
28.10.2015 04:09наверное, даже testing у Арча держится в более-менее приличном состоянии. Что-нибудь временами разваливается в хлам, но это горе-горе, и это будут чинить
Нет. Потому на testing и не рекомендуют сидеть. Там систему разваливают часто и со вкусом.
immaculate
27.10.2015 10:40+2Дистрибутивы существуют для того, чтобы установить систему, в которой мы работаем или которую используем для развлечения. Поэтому, по большому счету, неважно, как устанавливается дистрибутив и пакеты в нем. Я вот не устанавливаю систему каждую неделю, и пакеты тоже. У меня уже есть сложившийся набор инструментов, если я что-то и доустанавливаю раз в несколько месяцев, то мне неважно, есть ли у установщика GUI и какие у него опции командной строки. Запомнить пару ключей apt-get и pacman в состоянии каждый пользователь Linux.
Комментарий про пользователей Ubuntu унизительный и бестолковый (о том, что мы якобы выполняем неизвестные команды с форумов).prog666
27.10.2015 10:52В убунту чтобы поставить последние версии чего-либо приходится гуглить PPA, в Arch же все всегда имеет последнюю версию по-умолчанию.
immaculate
27.10.2015 11:01+5Не так уж часто приходится искать что-то в PPA. Зависит от конкретного пользователя, конечно, но думаю, что большинству редко требуется обращаться к PPA.
Вообще, я критиковал автора статьи, потому что он приводит эмоциональные ни на чем не основанные аргументы. Много он видел пользователей Ubuntu, которые выполняют «perl -e ads*&T&^^%%*»?
Конечно, технический уровень пользователей ArchLinux выше, потому что даже для его установки требуется серьезное знание основ Linux и много чего еще. Но это еще не значит, что один дистрибутив лучше другого. Смотря с какими целями устанавливать. Если надо разобораться в том, как работает Linux от и до, то лучше ArchLinux, так как без этого вообще не получится его установить. Но это надо не всем пользователям.
Хочу сказать, что не надо высасывать аргументы из пальца и критиковать людей за другой выбор.serf
27.10.2015 11:52Конечно, технический уровень пользователей ArchLinux выше, потому что даже для его установки требуется серьезное знание основ Linux и много чего еще.
Пару команд в консоли, но вообще если нужно что-то специфическое, то в вики придется покоппаться этого не отнять. Но вот есть сборка Antergos с GUI установщиком (не пробовал правда) antergos.com/blog/say-hello-to-cnchi-v0-10-the-latest-and-greatest-version-of-our-installer
rudenkovk
27.10.2015 11:06+1И на сколько часто надо иметь последнюю версию по умолчанию? Я занимаюсь devops и разработкой, и меня, кое-где, устраивает и redhat/centos, хотя работаем с модными штуками и модными технологиями.
Пока ты крутишься в рамках уютного своего компика, ну может быть пары сервачков, которые админить по ssh не проблема, да пофиг какой дистрибутив. А вот когда у тебя приличный парк и надо управлять версиями, а при этом еще следить за целостностью дистрибутива (война с зависимостями), то тут уже совсем другой разговор. И как-то я сомневаюсь, что арч тут будет на высоте.prog666
27.10.2015 11:08+1Арч точно не для сервера. Арч нужен для собственного рабочего компьютера. В арче бывает что после обновления что-то отваливается, поэтому в продакшене его использовать нельзя.
rudenkovk
27.10.2015 11:15Так зачем рисковать системой, которая тебя кормит?
Я не говорю, что arch плохой дистрибутив, но это скорее пока хорошая поделка для образования, я не рабочая вещь. Кстати, в отличии от дженты. На дженте делались очень хорошие и серьезные проды и решения для разработчиков, еще в благословенные 2006-2010 годы, когда убунту только зарождалась, а арча не было. И кстати, как я понимаю, идеологию pacman они процентов на 80 содрали с портежа и оверлеев.prog666
27.10.2015 11:17арчем пользуюсь уже больше года. Работаю каждый день на нем, потом прихожу домой и с него же сижу дома. за это время отвалилась один раз какая-то незначительная утилитка, которую кстати очень быстро пофиксили. Мне кажется она была из AUR даже.
rudenkovk
27.10.2015 11:28-3Я гламурненько работую на макоси, и у меня уже ничего не отваливается, даже homebrew уже лет 5. :)) Ну да это оффтопик.
У меня за это время побывали в руках парки из разных дистрибутивов, как серверных инсталляций, так и рабочих (и девелоперы, и графика, и просто рабочие, и терминальные). На опыте управления ПО и зависимостями, на любой, даже для себя домашний дистр выберу Ubuntu. Ровно по тем же причинам, что вы описали, как несомненные плюсы арча:
— целостное управление зависимостями
— хоть как-то оттестированные версии ПО и всегда есть в наличии свежии версии (кстати, не очень понимаю разницу между добавлением PPA и какого-то зеркала для pacman)
— адекватаня скорость работы, которая больше зависит от скорости диска и канала, чем от формата
— хорошо описаная процедура сборки пакетов. Есть такая штука OBS, которая вполне держит сборку под arch, но по факту, и при наличии arch-гуру в команде, оказалось проще перенести все на ubuntu, чем дальше сопровождать несколько наборов пакетов.
Собственно это все ведет к стабильности дистрибутива. И да, я не спорю, что если есть время и желание заниматься, то без разницы, что использовать как дистрибутив, но если ты поддерживаешь, хотя бы, кроме себя еще и жену с мамой, то тут целостность и стабильность дистрибутива становится куда актуальнее скорости работы pacman и последних версий nginx в репе.
Собственно, моя критика проста, вы бы не опускались на охаивание убунты или другого дистра, а постарались бы показать, как людям, не только для дома, но и в более широком смысле можно было бы применять arch.prog666
27.10.2015 11:53+1между добавлением PPA и какого-то зеркала для pacman
ни разу ничего добавлять не пришлось, все отлично ставится через yaourt.
В остальном — личный выбор каждого, никого не уговариваю бросать убунту и переходить куда-то еще.rudenkovk
27.10.2015 11:58Может быть. Я тут не спорю. Просто разный подход к управлению пакетами. Я тут только уповаю на предсказуемость и стабильность.
serf
27.10.2015 11:57+2Arch хорош для разработчика допустим, как правило все нужные тулы разработчика амые свежие «из коробки». В продакшен конечно я бы не рискнул его ставить.
rudenkovk
27.10.2015 12:03Я выше писал, что если вам надо соответствие по версиям с продом. Например, для тех C программеров, виртуалки и контейнеры не являются панацеей из-за быстродействия.
Я не спорю, что в рамках python/ruby (& etc) все решается через аналоги bundle/virtualenv. И тут уже не важен дистрибутив. Но, в рамках того же питона, представьте, что вы пилите, что-то активно завязанное на numpy, scipy, pandas (а это частый вариант), то у вас вопрос управления не только виртуальным окружением встает, но и тем, как собраны базовые либы в системе. А уходить на виртуалку, это увеличивать сборку проекта в несколько раз.serf
27.10.2015 12:05Для специфического окружения есть всякие контейнеры (докер и прочее), это уже не важно какой линукс использовать. Я имею ввиду удобство системы для разработчика в целом.
rudenkovk
27.10.2015 12:13-1И я вам о ровно том же самом. Удобство системы для разработчика. Пока вы пилите LAMP или рельсы у вас не возникает проблем. Когда вы начинаете пилить, что-то более капитальное, то зачастую никакой докер вам не будет панацеей. Это уже пройдено и не раз.
Это хорошо, когда у вас программер может написать себе локальненькую системочку сборочки, которая ему докерочек подтянет и в нем соберет и протестит. Но в большинстве случаев это не так. Потому что начинаются проблемочки интеграции в IDE (и даже в vim), получается, что результатики тестиков в контейнере и на локалочке с убунточкой (предполагаю, что прод на убунте) разные. И многое многое такое, что заставляет вас, при наличии всяких замечательных и модных технологий, вроде docker, унифицировать свое локальное окружение с продом.
PS проститей мой слог, как раз подобное сейчас решаюserf
27.10.2015 12:17Это вы уже уходите в devops/админские/архитектурные дела от разработки как таковой.
rudenkovk
27.10.2015 12:19А это не связано разве? Или мы говорим о сферическом программисте в вакууме, который только для себя пишет?
serf
27.10.2015 12:21Далеко не во всех проектах требуется унификация OS разработчиков и прода.
rudenkovk
27.10.2015 12:27Вы меня не внимательно читали? Я выше объяснил несколько случаев, когда это актуально. Я не говорю о том, что это повсеместная практика должна быть.
Я изначально утверждал то, что каждый работает в том окружении, которое ему удобно. И очень многое зависит от проекта и культуры разработки.
В отличии от автора статьи, я не пытаюсь объяснить, что убунта лучший дистрибутив на свете, а арч говно. Я говорю о том, что я легко представляю варианты, когда дистрибутив отличный от прода тормозит или ухудшает работу, или производительность труда.serf
27.10.2015 12:30С этим нельзя не согласиться, конечно арчик не является серебрянной пулей, как не является никакой другой дистрибутив.
rudenkovk
27.10.2015 12:35Вот именно. Бинго :)))))
В принципе мой тезис можно свести к следующим пунктам:
— если у вас простой проект на LAMP (я тут понимаю отсутсвие большого количества С/Go/Rust кода): дистрибутив не принципиален
— у вас нет требований к скорости сборки проекта (ну скажем ± 5 минут вам не играют роли) и можете собирать в виртуалке/контейнере: дистрибутив не принципиален
— но как только вы выходите за эти два условия, то вам уже требуется унифицировать свой дистрибутив с продом
(например, если у вас идет методология TTD и нужно проверять на лету в IDE результаты набора тестов, где есть привязка к версиям библиотек, ну и тд)serf
27.10.2015 12:38+1как праваило работаю с java и веб (js), проблема с унификацией никогда не было.
serf
27.10.2015 12:40Да и допустим в моем текущем случае получить окружение прода локально вообще невозможно, там все в каких-то облаках крутиться (что-то SAP/HANA специфичное). Java планформа сама по себе дает не плохую абстракцию от системы и железа.
rudenkovk
27.10.2015 13:14Ну опять же, это частный случай.
Как и у меня: у меня полный стек научных утилит на питоне (numpy, scipy, pandas & etc), и свои питоновские либы, которые являются биндами к С и Go коду. Да, я могу достаточно быстро поднимать у себя на макбуке нужную среду выполнения, но для меня не критична скорость сборки. Но для разрабов, все как раз наоборот. Им важно запускать софт у себя локально и без прослойки на виртуализацию, и в среде максимально приближенной к проду. Им ждать, когда в виртуалке (проверено в разных и со всеми оптимизациями) соберется проект и пойдет тестится за 30-40 минут, или когда это собирается за 10 минут локально. Безусловно докер на во многом выручает, но и там не все гладко. И по факту, мы пришли к тому, что у нас большая часть людей сидит на обычном 14.04, и даже не особо хочет обновляется выше. Работает не трогай. :)
Ну и да, те кто у нас пишет фронты, довески на lua, и тд используют приличный зоопарк дистров, но при этом есть вполне заметный тренд на унификацию дистрибутивов в команде.
fshp
27.10.2015 16:06У меня на работе проекты собираются под старый дебиан 32 битный.
У меня не возникает никаких проблемы что бы собрать проект в chroot на 64 битной системе и там же его запустить и отлаживать. 3D ускорение работает, звук есть. Проблем никаких.
oldbay
27.10.2015 15:49Некоторые хорошие люди пытались развивать проект Arch Server со стабилизацией пакетной базы и более гладкими update-ми. Имелся даже опыт поднятия на его базе сервера бездисковой загрузки рабочих станцй — остались весьма приятные впечатления от использования.
Увы и ах — проект «приказал долго жить».rudenkovk
27.10.2015 15:59Вообще странное дело. Возможно я совсем не в теме, но на дженту сделать серверную инсталяцию было просто. И контроль вресий пакетов всегда был. А возможность делать бинарные оверлеи для портежа, решали все вопросы с скоростью обновления.
Странно, что такое не могут запилить в арче. Думается мне тут архитектурно-идеологический баг.oldbay
27.10.2015 16:14+1Серверное использование арча всегда упиралось в неровные update при обновлениях + очень примитивный инструмент маскировки + невозможность отката обновлений и всё это усугублялось железобетонными зависимостями и блокировками между пакетами. Каждый раз ступать на минное поле при update на боевом сервере — не лучшее занятие.
Относительно gentoo, в арче нет: глобальных USE-флагов (только то что руками указано в pkgbuild-е), слотов, многоверсионности пакетной базы, гибкой маскировки версий. Всё выше указанное делает его более жёстким, прямым и примитивным относительно генты (зато и прозрачным в смысле архитектуры) — но это скорее издержки филосфии KISS.
olegchir
28.10.2015 00:27+2Думаю, дистрибутив прежде всего — это о культуре комьюнити, которое выполняет integration development
Когда у тебя комп не для того чтобы слушать музычку во вконтакте, а реально многоцелевая серверная машина, под которую твои программисты (или ты сам) девелопят кастомный софт, ты какбы сам становишься частью команды разработчиков дистрибутива
Читаешь новости, бесишься в срачах в devel-рассылках, каждое решение в дизайне системы воспринимается лично, ты знаешь в лицо (в аву на гитхабе) каждого чувака который сделал вот этот уродский конфиг или ключик, итд итп
Так что по сути выбор дистрибутива — это как выбор нового места работы. Ты выбираешь людей, с которыми тебе потом долго-долго жить вместе.
oldbay
27.10.2015 10:50+8Хороший Arch Linux был дистрибутив — пока его не покорёжили 3 года назад — а именно сломали собственное железное правило, что все основные глобальные настройки расположены в rc.conf. Уже в то время из rc.conf стали расползаться настройки сети, запуска модулей и окончательно меня добил отказ от удобнейшей bsd-шной системы инициализации арча (демоны перечислялись в переменой в порядке их запуска) и переход на, в то время еще сырую, systemd.
Были еще неприятные мелочи связанные с невозможностью downgrade пакетов — но эта мелочь имела ряд адекватных решений, которые в большинстве случаев и не требовались.
п.с:
Сейчас уже давно обжился на Gentoo — но до сих пор очень тепло вспоминаю этот дистрибутив, с его KISS-ом, простыми и понятными правилами написания pkgbuild-ов, обширнейшим AUR-ом (где оставил довольно много пакетов) и безвозвратным стремлением к upgrade всего и вся и раньше всех, порой в ущерб стабильности.
Fr0stb1te
28.10.2015 18:49+1Я в свое время очень обиделся на отказ от bsd-style скриптов загрузки, но от арча отказываться не стал. Вместо этого полез разбираться, как работают эти самые скрипты. Выросло это в персональный мета-дистрибутив, который на днях обзавелся неким подобием релиз-цикла (я планирую обновлять тарболл rootfs раз в месяц): https://fleshless.org/pages/spark.html
Из фич: написал простенький сервис-менеджер, вернул часть конфигурации в rc.conf, который, кстати, является скриптом. Сеть оттуда настроить можно тупо с помощью iproute2.
Это я не к тому, что этим надо пользоваться, а как пример того, насколько арч гибкий. Поддержка всего этого добра у меня занимает заметно меньше времени, чем поддержка собственной приватной инфраструктуры :)
rudenkovk
27.10.2015 10:50-3Или автор холиварит, или фанат арча без опыта с негативным опытом по другим дистрам.
prog666
27.10.2015 10:51+1Я разделяю любовь автора к дистрибутиву ArchLinux, но весь смысл его в том что тебе не нужно читать никакие статьи чтобы пользоваться им. Открываешь вики, делаешь загрузочную флешку — и понеслась!
kulinich
27.10.2015 11:04+4тебе не нужно читать никакие статьи...
Открываешь вики...
Вообще первое время только и приходилось, что читать.evilsprut
27.10.2015 16:08+1Видимо автор хотел сказать, что дистрибутив и почти весь софт можно изучить из официальной документации, а не чьих-то юзеркейсов. Изучать действительно нужно много, но Arch Wiki (в английском варианте) почти полностью перекрывает необходимость лезть куда-то ещё за дополнительной информацией.
ParkeTg
27.10.2015 11:13Ваш perl-script не работает. Даже от рута. Видимо, разработчики rm решили защитить неопытных пользователей от подобных шуток.
rm: it is dangerous to operate recursively on ‘/’
Эх… а так хотелось…evilsprut
27.10.2015 15:53Скрипт не мой. Это старая шутка про приветливость Linux-сообщества. Хорошо, что сейчас делают какую-либо защиту от подобных вещей, чтобы не случалось факапов как с bumblebee
mifki
27.10.2015 11:22+2У Арча все прекрасно, кроме одного — Digital Ocean на него забили.
ForeverYoung
27.10.2015 13:50+1Есть скрипт, с небольшими поправками (в тот момент нужными) отработал, сервер с тех пор успешно работает (для своих pet-projects, на рабочий production лучше ubuntu/debian ИМХО).
evilsprut
27.10.2015 15:38Archlinux менее популярен на серверах из-за особенностей системы. Обычно используют CentOS или Ubuntu из-за более простой настройки и наличия минимальных конфигов из коробки, а ещё на Archlinux гораздо меньше мануалов и юзеркейсов в сети.
serf
27.10.2015 17:04+2а ещё на Archlinux гораздо меньше мануалов и юзеркейсов в сети.
Видимо потому что у арча хорошая wiki документация
saggid
27.10.2015 12:10+7Прекрасно, когда представители одной религии стремятся поделиться своими знаниями с другими людьми. Культурный обмен знаниями — это чудесный способ обогатить и расширить свой кругозор.
Но вот когда один религиозный представитель начинает намеренно подтасовывать и искажать факты в стремлении возвысить свой путь и унизить другие пути — то это явно говорит о нечестивости этого религиозного представителя. Вот через такие статьи и возникают впоследствии заблуждения, а истина и прямой путь покрываются завесой предубеждений и некорректных доводов.
Так давайте же будем заниматься культурным обменом знаниями на основе правдивых аргументов. Ведь это в итоге станет благом для всех людей.
Всё, что вы описали про Ubuntu — просто наглая ложь какая-то, честно. Прекрасная ОС, никакого GUI ей нафиг не надо, всё легко и просто админится через консоль. Не говоря уже о простоте настройки — я лично легко собираю и настраиваю новый вебсервер на убунте за ~20 минут набивания всяких команд в консоль и правки пары конфигов в sshd_config, nginx и php-fpm.
Все остальные доводы даже не требуют того, чтобы на них обращали внимание.evilsprut
27.10.2015 15:17+1В статье я использовал Ubuntu, чтобы показать различия двух дистрибутивов, не более. Ubuntu замечательный дистрибутив, который я сам ежедневно использую на пачке серверов. Естественно, что софт обоих систем в общем одинаковый и для Ubuntu тоже есть образ mini, где можно всё поставить ручками, но разговор про отличия стандартной поставки и идеологи системы.
Вы привели отличный пример. Попробуйте установить своё веб-окружение на Archlinux, думаю разницу с Ubuntu заметите сразу. Archlinux почти всегда предлагает софт с минимальными зависимостями и без настроенных конфигов, а Ubuntu в свою очередь поставит минимальную рабочую конфигурацию, нужно вам это или нет. Да, конечно есть ключ --no-install-recommends, но различие именно в идеологии системы.
Сожалению, если ввёл вас в заблуждение.
FSA
28.10.2015 07:01Помню как-то пытался поставить какого-то клиента под IRC (как ни странно им до сих пор пользуются). Всё бы ничего, только в комплекте с ним прилетела… KDE. Позже его же ставил в Gentoo. Оказалось KDE, собственно, не нужен. Ubuntu прекрасная ОС.
iandarken
27.10.2015 12:53+1Я не помню, тут вроде какая-то кровавая ненависть к Лурку, но тем не менее — статья http://lurkmore.to/Arch дает бОльшее понимание о системе, плюсах и минусах.
И вот зачем трогать убунту, не имея достаточного опыта работы в ней? Я не удивлюсь, если у автора был опыт исключительно «Поставил с флешки Юникорна, погонял денек, снес». Давайте я тоже покидаюсь тезисами.
За несколько лет я Синаптик запустил только один раз — посмотреть. Все остальное время намного удобней гонять apt
За несколько лет я, когда мне нужны были базовые скиллы настройки FTP/HTTP/Open-чего-бы-то-ни-было и прочего — находил ответ на форумах Убунты. Гугл почему-то не смог выдать мне решения для кучи мелких проблем в виде линков на АрчВики. Сферичиские мануалы в вакууме — это хорошо, но конкретные кейсы описываются ими как-то не очень.
За несколько лет мне ни разу не пришлось использовать PPA, в стандартных репах все было.
За несколько лет я в гуях настраивал по сути только то, что имело отношение к гуям — обои да оформление окошек. Для всего остального как-то хватало vimskobkin
27.10.2015 14:31+1Не в защиту автора или статьи (там не всё хорошо), но ваши тезисы — это «за несколько лет мне», что не очень репрезентативно. В любом сообществе всегда можно найти кого-то, у кого всё работает.
Но если уж говорить про «у меня», то я вот с Ubuntu слез на Gentoo. И не потому, что у меня была какая-то проблема с APT (это вообще что-то притянутое за уши), а потому, что хотелось большей гибкости и аскетизма.
При этом противопоставлять их друг другу смысла нет, у них просто разные ЦА. Вот Ubuntu можно кому-нибудь из родственников, кто пользуется в основном плеером и браузером, спокойно поставить — там всё очень просто.
J_o_k_e_R
27.10.2015 14:50+4Другим руководящим принципом развития Arch Linux является свобода. Пользователям не только разрешено принимать любые решения, связанные с конфигурацией системы, но и выбирать, какой их система должна быть.
Уже можно откзаться от systemd?evilsprut
27.10.2015 15:31К сожалению для некоторых пользователей, нет. Система поставляется в пакетах, а systemd очень глубоко зашит. В сообществе было дикое бурление говн на эту тему, но в итоге выбрали systemd. Тяжело сказать хорошо это или плохо, каждому своё, но факт невозможности отказа от systemd огорчает.
oldbay
27.10.2015 15:41Мантейнеры арча — когда вводили systemd, сообщили следующее: что пока sysvinit они не выпиливают из репозитория, но больше не поддерживают — кому нужно пишите init скрипты на демонов сами. После чего повесили блокировку на systemd относительно sysvinit + сделали systemd зависимостью для udev(«экие» хитрецы) — чтобы побудить пользователей к переходу на новую систему инициализации.
evilsprut
27.10.2015 15:44С одной стороны хорошо, что заботятся о пользователях, с другой, systemd выпилить всё равно нельзя.
oldbay
27.10.2015 15:52Про что я и говорю — systemd пускает очень глубокие метостазы в любой linux и arch здесь не исключение. Вообще подозреваю, что по прошествии нескольких лет, из дистрибутива давно выпилили любые другие альтернативные системы инициализации.
stychos
27.10.2015 22:31Вот мне, как не особо секущему в плюсах-минусах, эта тенденция в принципе нравится. Я люблю Gentoo и OpenRC, они реально крутые, но меня всегда печалило, что в каждом дистрибутиве, и в особенности в Ubuntu с их Upstart — куча костылей и мест, куда надо смотреть, это всё немного раздражает. Пусть даже через силу, и ломая привычки — но если systemd станет основным и стабильно используемым механизмом инита на всех дистрибутивах, то я не против. Ну а что там под капотом, меня как пользователя уже не очень интересует, по скорости он вроде не хуже чем тот же апстарт, OpenRC, и уж тем более чем SysV.
oldbay
27.10.2015 15:32Увы нет, как и на большинстве современных дистрибутивов. Поттеринговы поделки начинают сильно нервироывать путаясь под ногами: то pulseaudio везде пихали «где не поподя», а с недавних пор новая беда — systemd :). Более-менее успешно этому зачилию «поттерингизмов» противостоит только одна gentoo со своими: apulse, openrc, eudev.
grossws
28.10.2015 04:37eudev
Прекрасно потёртые копирайты, да. При этом в той же убунте использовали upstart и прекрасно собирали udev из дерева исходников systemd (до текущего отделения), видимо не имея тайного знания холиварщиков о том, что udev в дереве исходников systemd не должен работать без systemd в качестве PID 1.oldbay
28.10.2015 11:06eudev — привёл только как пример(возможно неудачный), в gentoo прекрасно собирается и работает udev без вяких «еретических» systemd с «правоверным» openrc :)).
grossws
28.10.2015 15:21Для меня крики про «поттерингоподелки», превосходство eudev давно уже стали маркерами определенной категории хейтеров.
Поясню. Обычно аргумент про eudev приводился с момента, как udev объединили с systemd, и хейтеры начали кричать, что udev теперь невозможно использовать без systemd. Что совершенно не так, и debian, ubuntu, centos6 вполне подтверждают это. Они использовали udev, собирая его из дерева systemd без каких-либо проблем, и использовали совместно с upstart как PID 1.
Так что eudev — плохой аргумент. А стирание копирайтов оригинальных разработчиков ставит его на одну полку со всякими bolgenos.
nagibat0r
28.10.2015 07:08+2Вот я кстати говоря хотел узнать, зачем так ругаются на SystemD? Сначала он мне показался диким, новое же… Но сейчас прочитал всю документацию по нему, пишу сервисы для него. и знаете, мне он кажется проще, чем Sysvinit. Да и мой ноутбук запускается за 6 секунд с Systemd. Уже достаточно давно использую его, пока нареканий не было, успешно используется на 14 серверах, на рабочем ноутбуке и на двух ноутбуках дома. Это не реклама Systemd, просто хотелось узнать, чем он так плох?
С другой стороны, навязывание чего-то мне тоже не нравитсяrudenkovk
28.10.2015 08:39+2С одной стороны мы только готовимся к переходу на systemd (живем на 14.04 LTS, соответсвенно 16.04 LTS будет уже с systemd). С другой у нас было куча заходов на centos7 (тут скорее по велению бизнеса), и полет с тамошним systemd был вполне нормальный. Так что подпишусь я этим сообщением на веточку людей послушать.
oldbay
28.10.2015 11:43Чтобы не повторять одни и те же доводы против systemd — сделаю репост на критику Патрика Лойера из сообщества gentoo с доводами которого в основном согласен.
От себя хочу добавить, но только коротко:
— мне не нужен внутри оси разжиревший монстр нарушающий основной постулаты философии Unix и имеющий поведение раковой опухли — начался как система инициализации демонов, после чего стал вбирать в сбя: сеть, udev, dbus и т.д, скоро видать еще и с pulseaudio сольётся в экстазе… мне не нужен, в результате — монолитный, неподвижный, немодифицируемый монстр systemd linux;
— мне безразлично с какой скоростью стартуют серверные демоны(с чего вся эта «байда» с systemd и началась) — 10 секунд или 5… и на данных системах не требуется параллельного их запуска — больше волнует отрабатывание их взаимозависимостей при старте (с чем openrc прекрасно справляется);
— и наконец, зачем ломать одну из основ операционной системы, к коим, помимо ядра и основной библиотеки С glibc, относится система инициализации — это равносильно выдёргиванию позвоночника из всё еще живой крысы и имплантации вместо естественного органа гофрированного канализационного шланга… и еще удивляться потом: «и чего зверюшка то сдохла — мы же дали ей гораздо более совершенный орган нежели этот устаревший позвоночник».
Prototik
28.10.2015 14:46+1мне не нужен, в результате — монолитный, неподвижный, немодифицируемый монстр systemd linux;
Монолитность зашкаливает:
$ find /usr/lib/systemd -executable -type f | wc -l
58
и наконец, зачем ломать одну из основ операционной системы, к коим, помимо ядра и основной библиотеки С glibc, относится система инициализации
О да, а когда у нас было по 4-5 систем запуска — всё было круто и канонично. И есть системы (и их, кстати, много), где вообще нет инита.
Fr0stb1te
28.10.2015 19:01Short answer: https://fleshless.org/pages/spark.html
И это не единственный такой проект, просто этот мой, а потому под рукой всегда.
Конкретно этот требует понимания, как оно все работает, потому что ментейнер из меня, как из говна пуля. Поставить тот же OpenRC и связанные с ним пакеты, по статье в вики, занимает 10-20 минут и вполне себе работает.
xanm
27.10.2015 14:59+3Как-то ставил Arch на Macbook pro, и это было незабываемое путешествие по манулам. Особенно стало весело когда все дравера под графику падали с ошибкой)
Rosscian
27.10.2015 15:52Как-то, рассматривая различные дистры, наткнулся на любопытный экземпляр — AntergOS. Полностью основан на арче, не использует своих реп, в отличие от Manjaro, однако при этом, можно сказать, совершенно противоречит философии арча. Есть графический инсталлятор, один в один с убунтовским, при установке выбираешь DE, подключать ли AUR и еще некоторые вещи. После установки полностью рабочая система, но, естественно, много лишнего, так как сами пакеты ты выбрать не можешь. Зато wi-fi работает уже на этапе установки.
В целом, можно его предложить как альтернативу той же Ubuntu. Часто его предлагают для облегчения знакомства собственно с арчем, но что-то подсказывает, что начинать знакомство лучше все-таки с установки.
stychos
27.10.2015 22:18Почему линукс-сообщество не договорится сделать общий для всех дистров установщик пакетов, который будет поддерживать как бинарники, так и рецепты, как репозитории, так и скачанные бинарники, а для гиков — чтобы и USE-флаги, или как-бы-их-там-ещё-обозвать, ну в общем зависимости к пакетам? И да, было бы отлично реализовать это в ядре, хотя и как бы задача не для ядра, но зато убрало бы множество головной и прочей боли с миллионами дистрибутивов, чтобы с точки зрения нубасиков вроде меня это работало, ну, допустим, как make menuinstall для ядра — скачал файлик, запускаешь как исполняемый, а ядро его распаковывает, проверяет подписи-сигнатуры и запускает установщик, ну примерно как установщик драйверов для nvidia, только чтобы работало для всего и везде, и чтобы для репозиториев была общая команда, например install. Ой, install уже занято, ну и ладно…
ZoomLS
27.10.2015 22:23+1Это на словах круто звучит. В реальности же — труднореализуемо. Есть много важных задач, которые нужно сделать. Даже если всё бросить, нужно очень много людей и компаний как-то скоординировать вместе и договориться. Это может занять годы.
stychos
27.10.2015 22:25Ну те же KMS и KVM как-то сделали, договорились, хотя это задачи посложнее, на мой взгляд.
aik
27.10.2015 22:29+1Потому что это не линукс вей. Даже если и все нынешние договорятся, найдется куча народу, который форкнется и начнёт пилить своё. И опять получим сегодняшнюю ситуацию.
stychos
27.10.2015 22:35Ну и пусть форкаются — наличие lxc в ядре никак не мешает всяким докерам и OpenVZ, тем не менее для меня важно, что такой механизм есть, что есть он практически на любой системе из коробки, и что я могу его использовать, ну а время уже покажет, насколько это полезно и в какую сторону улучшать.
janekprostojanek
28.10.2015 11:23Такой механизм в ядре уже есть. Называется ./configure; make; make install.
stychos
28.10.2015 15:57Ну это, мягко говоря, не в ядре, и требует наличия компилятора. Я говорил о чём-то elf-оподобном.
janekprostojanek
28.10.2015 18:52Чтоб бинарники тянуть все время?
stychos
29.10.2015 23:01Ну для желающих же всегда останется make. Я о механизме для нубасиков вроде меня, чтоб было «как в винде», или «как в маке» — программа может размазываться как угодно и куда, но для меня это должно быть прозрачно. Впрочем, меня уже убедили, что это нереально.
janekprostojanek
01.11.2015 19:13И не только нереально, но и нехорошо! Это ж не винда, где все может размазываться хоть куда, а вы потом тонете, извините, в гов… ще, как в Авгиевых конюшнях.
У меня в Ubuntu, моем первом дистрибутиве, как-то этак все размазывалось, а потом она упала. В конвульсиях.stychos
01.11.2015 19:50А разве сейчас пакеты в линуксах не размазываются тонким слоем по файловой системе? Я что-то пропустил?
Fr0stb1te
28.10.2015 18:54tar. Я не шучу.
UPD: на самом деле немного шучу.
Например, pacman никак не привязан к арчу. Его можно использовать в любом дистрибутиве. Проблема — пакеты собираются под дистрибутив. Тут надо стандартизировать VFS layout, названия пакетов, ВСЕ ДО ЕДИНОГО пути…
Проблема не в пакетном менеджере, в общем.stychos
29.10.2015 22:58Беру свои слова обратно насчёт ядра, там это действительно нереализуемо — особенно с учётом того, что про юзерспейс и используемую файловую систему оно ничего знать не должно. Думал, что система должна предоставлять песочницу для приложений, в том числе и для их установки, и сама класть устанавлемые компоненты в нужные места по спецификации — но потом понял, что примерно так оно, например, в iOS и работает, что не отменяет жуткого бардака в файловой системе и там. Ну и тогда сообщество точно завоет от того, что у него «забирают свободу».
janekprostojanek
28.10.2015 01:08На этом пока все. В следующий раз мы установим систему с нуля и до рабочего окружения. Спасибо.
Я дико извиняюсь, а что автор считает рабочим окружением? Для меня и голая консоль — вполне себе рабочее окружение.
Вообще, материал о чем? «Есть такая система Арч, в ней все дико сложно, но это дело вкуса, а мы не такие.» Так я увидел эту статью. :)
ValdikSS
28.10.2015 02:31+3Ну, честно говоря, статья ни о чем, по сути. Я пользуюсь арчем, как и другими дистрибутивами, уже лет 7, наверное, и у каждого дистрибутива есть свои плюсы и минусы. У арча мне не нравятся следующие вещи:
- Пакет с ядром затирает текущее ядро и его модули, а не сделан метапакетом, как в большинстве других дистрибутивов. При обновлении ядра пропадает возможность загрузить какие-то дополнительные модули к текущему, приходится либо временно откатываться до старого пакета с ядром, либо перезагружаться.
- Все ПО собрано без поддержки SELinux, AppArmor, что, в общем-то, если и 5 лет назад было приемлемо, сейчас уже как-то не очень. Ядро, опять же, не подписано.
Из плюсов:
- Все ПО свежее. Это здорово. Это так, как и должно быть на десктопе. Если чего-то нет в репозитории, оно есть в AUR, а если нет в AUR, то PKGBUILD пишется очень просто для любого, кто писал пару shell-скриптов.
- Пересобирать пакеты очень просто. Пакет собран не так, как вы хотите? Воспользуйтесь abs или yaourt! Программы для работы с репозитариями и AUR продуманы до мелочей, это очень воодушевляет, по сравнению, например, с Debian, где только одна мысль о сборке пакета вызывает у меня рвоту.
- Пересобирать пакеты очень просто. Пакет собран не так, как вы хотите? Воспользуйтесь abs или yaourt! Программы для работы с репозитариями и AUR продуманы до мелочей, это очень воодушевляет, по сравнению, например, с Debian, где только одна мысль о сборке пакета вызывает у меня рвоту.
oldbay
28.10.2015 13:52Тысячекратно согласен по поводу сборки пакетов и адекватности сборочных сценариев pkgbuild — они просто шикарны своей простотой написания. Настолько удобен механизм сборки пакетов в арче — насколько он заморочен в других дистрибутивах: особенно в сравнении с написанием spec-ов для «синтеза» rpm… от последних начинается диарея, логорея и суицидальные позывы. Даже, те же, gentoo-вские ebuil-ды намного более замороченные… хотя по правде, если отбросить все макросы от eapi, их тоже, теоретически, можно привести к простоте pkgbuild-ов.
rudenkovk
28.10.2015 13:54Товарищи, если не сложно, киньте ссылку на документ с описанием?
PS Я прошу не потому, что не умею пользоваться гуглом, а чтобы мы говорили потом на одном языке и в одних терминах.ValdikSS
28.10.2015 13:56На описание PKGBUILD?
wiki.archlinux.org/index.php/PKGBUILD
Вот типичный PKGBUILD (от OpenVPN):
projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/openvpnrudenkovk
28.10.2015 14:05Ну, в целом, те же яйца, только в профиль. По сравнению с deb или rpm. Видно, что многое учли.
Надо поработать, чтобы прочувствовать. Первый заход по засовыванию этого дела в obs был не безоблачным (какое-то время назад)ValdikSS
28.10.2015 15:01+3Все дело в мелочах. Хотите пересобрать пакет, скажем, конкретно под ваш процессор? Единожды настраиваете /etc/makepkg.conf, затем скачиваете интересующий вас пакет через yaourt -G или abs и выполняете makepkg -s. Все! Он сам скачивает исходники, сам удостоверяется, что они последней версии, сам устанавливает.
Мейнтейнеры еще не успели обновить версию пакета, а вы хотите ее собрать? Точно так же качаете исходники через yaourt -G или abs, изменяете версию внутри PKGBUILD и запускаете makepkg. И что, пожалуй, самое важное — все это задокументировано, инструмент для сборки один.
Что мы видим в Debian? Да ужас мы видим: документации для сборщиков пакетов довольно много, но она разрозненна и, зачастую, просто устаревшая. Программ для сборки пакетов, по меньшей мере, несколько: dpkg-buildpackage для ручной пересборки родных пакетов, debuild для автоматической пересборки родных пакетов, куча ПО из состава devscripts для работы с пакетом, а есть еще pbuilder. Хоть и чисто Debian-проблема, но приходится поддерживать и писать скрипты/правила сразу под три системы инициализации: systemd, sysvinit и upstart.
В общем, у меня много негативных впечатлений от системы сборки Debian, хоть она и очень, очень мощная сама по себе.
В RPM-мире, по крайней мере в Fedora, все заметно лучше, но, опять же, не идеально. Скачанные исходники, если их «устанавливать» через rpm, распаковываются в домашнюю директорию/rpmbuild, что не очень удобно. Их, конечно, не составляет труда перенести в нужное место, но, видите, все дело в мелочах. Документация к spec достаточно полная и подробная, пожалуй, такая же хорошая, как и у PKGBUILD. Но тот же rpmbuild не умеет качать недостающие исходники, и на странице, посвященной сборке, ничего не сказано про spectool, который может это делать. Ну вот как так, это же неудобно!
Я далеко не эксперт, и вообще, не-ArchLinux пакетов собрал не так-то и много, но, по моему мнению, излишне сложная и неудобная система сборки у Debian в купе с популярностью и распространенностью Ubuntu дала такой большой толчок общей контейнеризации врoде Docker. Если бы пакетировать ПО под Debian и Ubuntu было бы так легко, быстро и просто, как это есть сейчас с ArchLinux, заметно меньше людей бы предпочитали Docker только из-за того, что: «ой, лучше я docker-контейнер скачаю, а то опять чего-нибудь не соберется, и систему засру -dev-пакетами». Вот, кстати, удаление уже ненужных зависимостей, опять же, одна из слабых сторон apt и dpkg.ValdikSS
28.10.2015 15:11+1Хоть это и не относится напрямую к системам сборки, но, пожалуй, самая странная вещь в dpkg, которая меня максимально бесит — установленные сервисы запускаются сразу после установки. Да, это отключается, да, это мелочь, но я просто не понимаю, кому в голову пришло включить такое поведение по умолчанию, и кому это может быть удобно вообще.
Все эти мелочи заставляют задуматься, а не во мне ли дело, может я что-то не так делаю, что-то не то или не так прочитал? Да нет, похоже, все делают именно так, и всех все устраивает. Это очень демотивирует.rudenkovk
28.10.2015 15:14Это имело смысл, так как когда сие придумывали, не было всяких chef/ansible, и зачастую рабочий конфиг клали в пакет.
rudenkovk
28.10.2015 15:12Legacy у дебиан никто не отменял. Как и у rpm, В арче меня напрягает излишняя аскетичность. Хотя повторюсь, у меня тут нет опыта и я смотрю с позиции того, с чем столкнулся один раз, и как вижу процесс.
Далее, ИМХО, это не отменяет того, что если вы собираете, что-то новое/свое, вам нужно писать свои скрипты (или, как минимум проверять) для systemd. Далее, везде нужно писать правильную проверку, что и куда кладешь, куда идут конфиги. PRE/POST скрипты. Ну и в целом, мы получаем спеку/дебиановские метаданные, в несколько другом формате.
Появление контенеров, ну в целом да, согласен. Это имело вес. Особенно учитывая, как рьяно начали делать всякие rubygems, gvm и прочие maven, и как там тяжело стало заниматься пакетированием и зависимостями.ValdikSS
28.10.2015 15:25+2вам нужно писать свои скрипты (или, как минимум проверять) для systemd
В том-то и дело, что я бы предпочел писать только юниты systemd. У меня нет желания погружаться в пучины sysvinit-скриптов, я на них уже насмотрелся до systemd. По моему мнению, systemd — лучшее, что случилось с линуксом когда-либо. И дело, опять же, в мелочах, да и дело-то не в самом systemd с точки зрения системы инициализации (хотя и в ней тоже). Systemd умеет изолировать все сервисы в своих namespaces, ограничивать их через cgroups. До systemd-networkd, почти у каждого дистрибутива были свои скрипты и программы для настройки сети, какие-то были более удачными, какие-то менее, но, в целом, networkd уже их всех опередил. Я перешел на него только ради одной поддержки policy routing, что не могли нормально сделать ни в одном дистрибутиве за эти годы. Многие разработчики уже используют systemd-ask-password для запроса пароля в консоли при старте сервисов, это удобно. С systemd-run вы можете запустить какое-либо приложение как сервис, что раньше обычно приходилось делать в screen или еще как-либо костыльно. systemd-nspawn часто использую для продвинутого chroot, чтобы не запускать потенциально недоверенный контейнер с чем-либо в рабочем namespace.
Думаю, для большинства это такие мелочи, о которых можно только сказать «да зачем это нужно», но для меня они критичны. Написал бы статью об этом, но, боюсь, со стороны это выглядит как нытье.rudenkovk
28.10.2015 15:49Ну собственно плюсую и но коммент :)
В моем варианте ждем 16.04. А arch, как вариант, можно использовать для проигрыша базовых сценариев.
oldbay
28.10.2015 14:10pkgbuild это по сути обычный скрипт в котором по очереди указаны этапы сборки пакета — в том виде как если бы сами создали руками какой нибудь build.sh. Единственная разница в пакбилде есть заголовок с параметрами пакета(зависимости, контрольные суммы, блокировки и т.д.) и определены переменные указывающие на каталог сборки исходников ${srcdir} и каталог сборки бнарников пакета ${pkgdir}… есть еще ряд других переменных — имя пакета, версия и т.д. но они все в загаловке и так перечислены.
Всё кидаем в одну кастрюлю и варим до готовности — наблюдая за всей сборкой в терминале.
kresh
28.10.2015 18:57Спасибо за статью. А какие у вас бывали существенных затыки при работе с Arch? Используете ли вы Arch для Frontend разработки? Если да, то интересно какие программные пакеты вы используете? Есть ли какая-то ли наиболее удачная конфигурация железа для Arch? Я знаю что Thinkpad-ы хорошо совместимы. Собственно сам долгое время Mandriva на Thinkpad пользовался.
serf
30.10.2015 07:36Arch для Frontend разработки
И не только Frontend. В принципе для Frontend разработки как правило достаточно NodeJS (автоматизация всяких задач) + IDE + возможно что-то для нарезки PSD (если верстка необходима) — у меня это просто assets.adobe.com (верстаю очень редко и мне хватает, есть еще плагин Extract для Brackets с подобным функционалом). Затыков не припомню.
По железу просто заранее прогуглите интересующие модели, плюс в вики что-то есть по некоторым моделям, например по моей машинке wiki.archlinux.org/index.php/Dell_Latitude_E7440
Amet13
29.10.2015 05:58На этом пока все. В следующий раз мы установим систему с нуля и до рабочего окружения. Спасибо.
Зачем? Если в вики все описано?
barker
з.ы. я был уверен, что читал эту заметку, поискал — оказывается, пролежало в песочнице больше 2х лет.
FSA
Вполне себе установил без проблем на свой компьютер. Потом, правда, не смог справиться с драйвером видеокарты. После этого решил попробовать Gentoo где встретился с той же проблемой. Проблему решил, но на Archlinux уже не вернулся. После FreeBSD Gentoo выглядит отлично.
Однако как бы хороши для меня не были Gentoo и Archlinux, я другим всё-таки советую что-то из *buntu или mint.
artoym
Я начинал с arch и, хотя так и не перешёл на linux, во многом разобрался и узнал. Установка Убунты не даст и 10% от этого. Установить и настроить у меня получилось не с первого раза, но подробнейшие мануалы на арч.вики просто превосходны.
ice2heart
LFS и BLFS Дадут больше чем арч.
artoym
А написания вообще всего с нуля ещё больше, но я говорю о том, что арч вполне подъёмен для абсолютных новичков, позволяя им чему-то научиться.
skobkin
Подъёмен, но стремление должно быть довольно сильным и терпения должно быть много. Gentoo тоже при большом желании можно собрать по хендбуку не пробовав линуксов ранее.
Однако, для того, чтобы не отпугнуть лучше с чего-то более дружелюбного начинать, как мне кажется.
stychos
Я вот с Gentoo и начинал, и до сих пор считаю её одним из лучших дистрибутивом. Но да, новичкам не советую. А сам в итоге и вовсе перешёл на хакинтош.
ice2heart
LFS тоже вполне прост, к тому же он гораздо более структурирован чем та жа вики. Просто читаешь книжку и тыкаешь палочкой в компилятор.
skobkin
Конфликт драйвера в ядре и проприетарного?
Ну да. Тем, кто спрашивает совета логично давать что-то попроще. Пройдёт время и, если им будет нормально в линуксах — они уже смогут либо сами найти, либо спросить, что есть более гибкое.
FSA
Я уже точно не помню что, но когда нашёл, то понял, что аналогичным образом я бы исправил это в Archlinux.
skobkin
Ну да. Большинство этих проблем с видеодрайверами общие для всех дистрибутивов.
barker