Homebrew для Linux

зыы: xtraeft у меня кажется в игноре. не люблю его читать.

Ага, у тебя бомбит когда ты с чем то не согласен.

что бы не собирать руками и иметь обновления?

да вот как-то и не приходится ничего собирать, кроме собственных проектов. все есть собранное.

Этот кусок говна практически не работает

Успешно поставил ponysay и ffmpeg. Хотя ощущается, что по сравнению с оригинальным homebrew пока сыроват.

Чтобы юзер мог ставить нужное ПО, не обладая правами рута

Но зачем?

Затем что программа может быть самосборной/редко обновляться в репах/из транка.

Почему бы ее не опакетить и не положить в локальный репозиторий?

Мусорить -9999 в /? Ну нет.

Лучше мусорить в ~, да.

можно было бы поднять борду или сайт или игровой сервер например.

Борда или игровой сервер захотели бы открыть привилегированный порт, для чего всяко понадобился бы рут.

Чтобы не давать юзеру права рута.

Лучше мусорить в ~, да.

да

Борда или игровой сервер захотели бы открыть привилегированный порт

Типа 12345? :)

Да и вот захотел юзер себе такую то версию php - пожалуйста, пусть ставит себе отдельную (или что, ему надо компилять руками?).

все шаред говнохостинги с доступом по SSH.

Ну разве что.

однажды был у нас кластер, где админ был за штабильность

У него наверняка были на то причины.

поэтому написал свою, которая <…>

развела несопровождаемую помойку с паролями открытым текстом на каждой ноде кластера, каковая помойка кроме всего прочего грозила потерей работоспособности при очередном обновлении системы.

Типа 12345? :)

Типа 80/tcp. Впрочем, для «поиграться» сойдет.

Типа 80/tcp. Впрочем, для «поиграться» сойдет.

Зачем это игровому серверу такой порт? Я их сто лет не видел, но всякие контерстрайки раньше висели на 20к+

Зачем это игровому серверу такой порт?

OK с ним, с игровым сервером, но борда (если я правильно понял это слово) может захотеть 80/tcp. Кстати, посмотри, за кем зарезервирован 666/tcp :)

Да и вот захотел юзер себе такую то версию php - пожалуйста, пусть ставит себе отдельную

Ее, если это не php-cli, всяко придется увязывать с системным апачем, энжинексом или какой там на хосте веб-сервер, для чего понадобится рут.

Именно php-cli (со встроенным веб сервером) для разработки.

Именно php-cli (со встроенным веб сервером) для разработки.

А потом при деплойменте окажется, что тот же php надо ставить централизованно.

Это другой вопрос, не относящийся к делу. А так - удобно, хоть 5 разных версий php держишь и устанавливаешь нужный софт самостоятельно по мере необходимости.

А так - удобно, хоть 5 разных версий php держишь и устанавливаешь нужный софт самостоятельно по мере необходимости.

Если комп лично твой и ты сам себе ССЗБ хозяин, то может быть, а если машинка конторская, то хотя бы в плане разделения труда лучше напрячь админа, а он пусть решает как может (я бы решал локальным репозиторием со всеми нужными php).

Алё, мы про МНОГОПОЛЬЗОВАТЕЛЬСКИЕ системы. Зачем звать админа на каждый чих, если можно ставить ПО для работы-экспериментов к себе в ~?

У него наверняка были на то причины.

да. работы много, некогда ему было 24х7 сидеть перед скайпом и ждать, чего же пожелают пользователи.

этого админа уволили (в этом есть и моя заслуга).

вместо этого большинство сервисов были переведены в облако, включая репозитории с кодом. Оставшиеся сервера мы настраивали как нам удобно, у меня был рутовый доступ.

развела несопровождаемую помойку с паролями открытым текстом на каждой ноде кластера, каковая помойка кроме всего прочего грозила потерей работоспособности при очередном обновлении системы.

совокупность бреда. Моя «помойка» никак не влияла на основную систему. Поддерживал я ее сам, больше о моей помойке никто и не знал (кроме негодующего админа). Все знают только о том, делается ли работа, как именно я ее делаю - не их дело. Пересобирал мир я раз в неделю точно, так что никакой проблемы с «упавшей помойкой» нет - она бы просто отправилась на очередную пересборку.

Зачем звать админа на каждый чих, если можно ставить ПО для работы-экспериментов к себе в ~?

К примеру затем, что рано или поздно результат работы с этим ПО надо будет деплоить (если говорить конкретно о php) или еще как-то использовать. Чем раньше админ узнает о таком, тем лучше для всех. Далее, если мы про МНОГОПОЛЬЗОВАТЕЛЬСКИЕ системы, то отличная от системной версия php (или чего угодно еще) может понадобиться более, чем одному пользователю данной системы — что, класть его каждому в ~? И в конце концов, с т. з. админа может оказаться проще централизованно развернуть (хоть бы и в /usr/local) непосредственно нужное юзеру приложение, чем устанавливать этот homebrew (написанный, к слову, на ruby) и необходимый ему рантайм.

1) админ не знает, что хочет девелопер

2) желания девелопера меняются раз в полчаса. Админ в конторе >100 человек вообще никогда не успеет за всем вот этим.

Итог — ты взял на себя еще и работу того админа. Если это всех устраивало, то я за вас рад (а если нет, то ССЗБ).

админ не знает, что хочет девелопер

желания девелопера меняются раз в полчаса

Проблемы организации труда.

А потом при деплойменте окажется, что тот же php надо ставить централизованно.

если при деплойменте окажется, что сервера работают на более старом PHP, чем это нужно для нашего кода - админ отправится устанавливать новый PHP

и тут возникает проблема, потому что от микрорелиза до микрорелиза (допустим, релиз софтины 1 раз в неделю в четверг) важных изменений может оказаться много, и админ сам без разработчиков об этом ничего не знает, и деплоймент точно будет фейлом

гораздо лучше чтобы все изменения делал админ вместе с разработчиком. Ну или просто разработчик, админ тут лишнее звено.

ну я как бы был релиз-инженером... никому не важно, какую работу я на себя взял, важно чтобы получился результат - выкаченный релиз, который работает. Если релиз не работает, трахать будут меня вне зависимости от того, накосячил я или админ, или господь бог

гораздо лучше чтобы все изменения делал админ вместе с разработчиком

Вот и я о том же.

Если релиз не работает, трахать будут меня вне зависимости от того, накосячил я или админ, или господь бог

Тем более не повод брать на себя лишнее. В конце концов, не вариант было бы взять админа за шкирку и сказать — так, мол, и так, для деплоймента нужно будет то и сё, как мы можем это обеспечить? И не за пять минут до дедлайна, а хотя бы за 10 :)

наш админ был в другой стране (кажется, в Ирландии) и отвечал на письма раз в 3 дня. Руководство было в США, разработчики в США, России, Индии, еще где-то. Если мне понадобилась бы новая либа на кластере, я ждал бы 3 дня ответа. При этом ответ мог быть вроде: «не, не буду ставить, говно какое-то». Я ответил бы ему с подробным объяснением зачем это нужно, и получил ответ через следующие три дня.

для примера, обновленной версии емакса я не долждался вообще. Месяц обменивался объясняющими письмами с интервалом в три дня, и под конец просто собрал емакс в хомячке. С емакса собственно и началось создание помойки. В дальнейшем я просто ставил на админа тикеты в редмайне на обновления либ (которые он почти никогда впрочем не выполнял), и сразу же отправлял питочнячий скрипт собирать эту же либу в хомячке на десяти машинах.

прости за простыню текста, просто меня эта тема до сих пор волнует, вызывает бесконечную ярость и ненависть

То есть как я и говорил — проблема организации труда (не знаю, кто в ней был виноват).

этого админа уволили (в этом есть и моя заслуга).

Если все сказанное тобой насчет обновлений и тикетов в редмайне верно, то правильно сделали.

прости за простыню текста, просто меня эта тема до сих пор волнует, вызывает бесконечную ярость и ненависть

Искренне сочувствую (без иронии). У меня просто взгляд с другой стороны баррикад — доводилось разгребать системы, ка которых было наворочено черт-те что, и что самое главное (и вызывающее у меня ярость-ненависть) — нигде не было ни строки документации о том, почему и для чего был наворочен тот или иной наворот.

установка пакетов в хомяк без sudo.

они изобрели 0install?

кстати, знаешь зачем пароли плейнтекстом? Потому что этот гений запретил логин по открытому ключу и порт-форвардинг. Видишь ли, это краеугольный камень системы безопасности. Даже если это и так, но работать так невозможно, ни один автоматический интеграционный тест написать не получится. В результате у меня скрипт на expect (точнее pyexpect) был на каждой ноде, и мог распространять текстовые команды по заранее заданному маршруту внутри сети. expect тут при том, что раз уж логин по ключу запрещен, мы будем ждать приглашения ввода пароля и вводить его самостоятельно плейнтекстом, впечатывать буковки прямо в эмулятор терминала (либа написанная на java). Все эти «наколенные текстовые туннели», конечно, адово тормозили и глючили. Добро пожаловать в ад!

кстати, знаешь зачем пароли плейнтекстом? Потому что этот гений запретил логин по открытому ключу и порт-форвардинг. Видишь ли, это краеугольный камень системы безопасности.

«Если за такое не убивать, за что тогда вообще убивать?» (В. С. Луговский).

Кстати про expect — возможно, sshpass слегка упростил бы жизнь. А может, и не упростил бы, просто я expect толком не осилил.

имхо, лучше всего, чтобы был какой-то скрипт, кукбук, еще что-то, который за 1-2-3 строчки разворачивает проект на свежесозданной виртуалке/сервере. И чтобы этот скрипт был написан так ясно и чисто, чтобы сам себе был документацией. Даже если что-то внезапно сломается, любой инвалид сможет развернуть всё из бэкапа. И не нужно напрягать мозг пониманием, как же блин это всё работает.

имхо, лучше всего, чтобы был какой-то скрипт, кукбук, еще что-то, который за 1-2-3 строчки разворачивает проект на свежесозданной виртуалке/сервере.

ansible и прочие средства управления конфигурациями rulez, хотя внедрять их (как и вообще что-либо новое) — отдельный геморрой.

И чтобы этот скрипт был написан так ясно и чисто, чтобы сам себе был документацией.

Ну это уж совсем идеальный идеал :)

Попробовал юзать http://concordion.org для интеграционных тестов и скриптов запуска. Документация пишется простым текстом (в HTML), и потом когда скрипт выполняется - в зависимости от того, выполнился он или нет, нужная часть документации становится или зелененькой (всё ОК), или зачеркнутой красным (не получилось).

К сожалению, такие тесты осилил писать только я и девочка-тестировщица. Программисты коллективно сказали, что код сам должен быть себе документацией. Любой кто понимает Java, поймет как всё работает. А кто не понимает - тот инвалид и ненужен xD А графический интерфейс вообще интуитивный, пользователь и без документации поймет. Итого - у меня такая крутая документация была только к основным интеграционным тестам.