«In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.»
Средняя кнопка мыши это не Ctrl+V — это вставка из выделения.
В никсах есть по умолчанию два буфера. Буфер выделения — в котором лежит то, что последним где-то выделили, и буфер обмена — куда копируется по Ctrl+C.
Ctrl+V вставляет из буфера обмена
Средняя кнопка мыши вставляет из выделения.
Да, он просто вращается согласно настройки. Просто цикл суточный стабильный, поэтому два независимых процесса вполне могут работать синхронно и синфазно.
Поработать будет мало. Очень велика вероятность создать дыры как в безопасности так и в стабильности. И тут надо широкое использование. К сожалению, в описанной в статье схеме это надо очень мало где :( И потому такое распределенное тестирование не получится.
На тему pluggable auth у меня вообще двойственное впечатление. Для nss я модуль рисовал просто по примерам. Никакой вменяемой документации не нашел вообще нигде.
Хотя уж сколько лет прошло, и сколько готовых модулей есть.
А у мускула это новое — я очень надеюсь, что пойдёт в массу. Очень хочется иметь коннектор в mysql auth (нет, я не извращенец, но хочется авторизовывать мускул из таблички в другом мускуле, или даже в этом же но в другой базе и по другой структуре размещения их) и ldap.
Не знаю как в случае с MS продуктами, на DRBD в случае факапа одного канала понижается скорость репликации, и просто запись на диск становится медленней.
В таких условиях переключение на более тонкий даже канал репликации вызывает тормоза, но не падение — а это уже допустимо для ситуации аварии.
Внешний же канал обычно резервный ощутимо тоньше — и это считается нормальным, держать 100%й резерв основного канала таки дорого; еще один момент почему лучше держать два канала по 50% и в нормальной ситуации использовать оба — в случае факапа канал урезается в два раза, но в обычном состоянии нет простаивающих мощностей.
А эти два ЦОДа разнесены далеко? Узел связи стоит на разных IXах у каждого цода?
А если не секрет — почему? У вас стоимость резервного канала константа, или по использованию?
У меня стоимость второго канала просто не окупается проектом, поэтому ограничиваюсь одним + vlan через public inet порт как резерв, и PI порт как раз по использованию тарифицируется — потому как резерв на случай факапа.
У вас, как понимаю, нормальная арендованная пара каналов, не вижу смысла не использовать простаивающие мощности.
Ну пока M$ не съехала с катушек по типу оракла — всё в порядке.
Решения вполне стабильные, а 5-10% потери производительности на массовом подходе не важны.
«In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.»
В никсах есть по умолчанию два буфера. Буфер выделения — в котором лежит то, что последним где-то выделили, и буфер обмена — куда копируется по Ctrl+C.
Ctrl+V вставляет из буфера обмена
Средняя кнопка мыши вставляет из выделения.
Хотя уж сколько лет прошло, и сколько готовых модулей есть.
А у мускула это новое — я очень надеюсь, что пойдёт в массу. Очень хочется иметь коннектор в mysql auth (нет, я не извращенец, но хочется авторизовывать мускул из таблички в другом мускуле, или даже в этом же но в другой базе и по другой структуре размещения их) и ldap.
В таких условиях переключение на более тонкий даже канал репликации вызывает тормоза, но не падение — а это уже допустимо для ситуации аварии.
Внешний же канал обычно резервный ощутимо тоньше — и это считается нормальным, держать 100%й резерв основного канала таки дорого; еще один момент почему лучше держать два канала по 50% и в нормальной ситуации использовать оба — в случае факапа канал урезается в два раза, но в обычном состоянии нет простаивающих мощностей.
А эти два ЦОДа разнесены далеко? Узел связи стоит на разных IXах у каждого цода?
У меня стоимость второго канала просто не окупается проектом, поэтому ограничиваюсь одним + vlan через public inet порт как резерв, и PI порт как раз по использованию тарифицируется — потому как резерв на случай факапа.
У вас, как понимаю, нормальная арендованная пара каналов, не вижу смысла не использовать простаивающие мощности.
Решения вполне стабильные, а 5-10% потери производительности на массовом подходе не важны.