Извините, но как можно проверить через stub_status на этапе сборки nginx а не поломал ли я логику хождения к upstream?

Первая задача которую решает этот модуль это представление кусков логики для возможности тестирования nginx'а на этапе сборки. Идея по применению для прототипов появилась только на выходных. А вот сейчас, как оказалось, удобно использовать для всяких заглушек поживому.

1) self testing nginx, для этого примемения оно и было написано.

2) создание быстрого прототипа.

Кстати, а с чего вы взяли что только пустой xml?

Нужен ответ определенного вида, с определенным типом. От xml'я до plain/text.

Раньше это реализовывалось на всроенном perl — с этим патчем, много проще.

Спасибо, поправил.

На bf я написал одну программу. base64 encoder/decoder. Она даже работает. Только вот ее поддержка ;)

я кстати написал программу которая пишет программу на этом языке ;)

Правда одну :(

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

Раз захотели эзотерику то вот основные языки и их цели:

*) INTERCAL — быть не как привычные
*) brainfuck — машина тьюринга, с простым и красивым синтаксисом
*) Befunge — n-мерные, piet это ответвление от этого
*) Chef — пишем программы как рецепты, был еще шекспировкие тексты. Кто-то из русских делал по мотивам пушкина ;)
*) Var'aq — логика Клингонов из Star Trak
*) Whenever — раскрашиваем рыбку ;)

И мой любимый: Malbolge, просто отрыв башки

На девелоперских машинах, про место, возможно. Но на тестовом стенде… Всегда можно сделать тестовый стенд более мощным.

Так же на тестовом стенде, хорошо бы, иметь базу реальную, не анонимизированную и не обрезанную.

md5sum от ключевых полей. Например от всяких имен клиентов и адресов. И вообще всегда можно в NDA поиграть.

А что мешает на тестовом стенде/у программистов использовать snapshot живой базы?

Скажем так, смысл есть всегда. Правда если вы живете на виртуальном хостинге, то да, тут его мало.

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

Теперь по софту.

Естесвенно нам нужен репозиторий для исходгого кода, который бы умел хуки. git, hg, svn и далее вполне подойдет.

Далее нам нужен сборщик пакетов, скорее всего у нас все будет внутри одной архитектуры. Ну или двух. amd64/i386. Для сборки нам будет нужен pbuilder, его хватит, да. Если хочется всяких извращений, то можно пойти qemubuilder.

Далее у нас идет управление репозиторием. Для этого можно взять dak (отрыв башки) или reprepro.

Теперь это все надо связать скриптами и начать перется ☺

Предпологается что под решение выделяется отдельная машина (и не одна) или отдельно vps.

у ftp/ftps есть passive и active mode, у sftp этого нет. Это *очень* веская разница в протоколе. Согласен?

С точки зрения пользователя? Возможно. Я смотрел именно с точки зрения протоколов и их реализации. И когда говорят что sftp это ftp over ssh подразумевают что взяли ssh и в него инкапсулировали ftp. И *это* утверждение ложно.

:( очень просто почему.

Вы сейчас не понимаете что такое sftp и как оно работает. Вы не понимаете что такое ftp и как оно работает. Так же вы не понимаете что такое ssh. При этом вы заявляете что sftp = ssh + ftp или ftp over ssh. Это утверждение ложно. И вы не хотите разобраться почему, вы просто продолжаете стоять на своем и ставить мне минусы. Это ваше право, да.

Но грусть мою, это все, вызывает и сильную.

Разные подходы, да, возможно.

Но sftp != ftp over ssh. Как бы этого не хотелось :(

По сути это не ftp over ssh. Говоря так, вы показываете что не знаете как работает ftp и как sftp. Это совершенно разные (!) вещи.

А, ccsh. Может-может. Не приходилось сталкиваться :(