Какие CMS являются современными с точки зрения архитектуры?

Если CMS не позволяет полностью изменить аутпут - она устарела по определению.

Как происходит работа SSL на нестандартно порту?

Архитектурно нормально. Только вот в сертификате SSl нужно потр тоже указывать. https://www.example.com:8100 != https://www.example.com:443 - требуют 2 разных сертификата.

Как правильно написать скрипт для автоматической записи звуков?

Не будет. Имя файла перенаправления вычисляется один раз.

В чём преимущество асинхронных серверов перед PHP/nginx?

> Если БД принимает тяжелый запрос, на который нужно, скажем, 100 миллисекунд, то она не сможет выполнять другие запросы на протяжении этого времени. Сможет. Если нету локов. И выигрыш будет.

DHCP server hardware requirements

<quote>И это тоже странно. На практике, если сеть 100мб/с+, то пара сотен устройств на VLAN — это мелочь, десятки/сотни кб/с мусора и всё.</quote> Тем не менее это факт. Со структурой броадкастов не разбирался. По поводу различий между L2 и L3 ежу ясно. Раньше всё, что L3 называлось раутерами. Потом появились устройства, которые обрабатывали пакеты на уровне L3 (IP заголовка), но не занимались сборкой/разборкой фрагментов, не могли анализировать тело, не могли изменять сами пакеты. Не имели WAN интерфейсов. Архитектурно они почти не отличались от свичей L2, единственное, что происходил поиск не только по MAC таблице, но и по таблице маршрутов, а потом уже и правил фильтрации. Архитектурно они есть серединка между L2 свичами и раутерами. С аппаратной акселерацией у них работает не только l2 фабрика, но и L3. Что важно, они не имеют очередь пакетов размером 1 пакет. Есть еще множество тонкостей. Через некоторое время действительно эти различия стали пониматься по разному и частично стерлись. Как и то, что раутеры начали уметь работах на всех 7 уровнях ISO-OSI. <quote>DHCP — мелкие пакеты. Даже до 1500 вряд ли доберутся. Если добрались, то администратор что-то делает неправильно.</quote> Имеется в виду следующее: у меня внутренняя сеть серверов работает с JUMBO. Клиентская сеть - без Jumbo. Если я через обыкновенный L3 switch пропишу маршрут. То произойдет следуеще: при jumbo ответе от сервера L3 свич форварднет пакет на L2 свич, но так как на L2 MTU меньше, а l3 не умеет фрагментировать - то пакет просто дропнится. (я понимаю, что некоторые L3 умеют даже нат - но тут уже маркетинг. В циско решили нет ван - свич, есть раутер. но сюда не лезем) по поводу радиуса. стоит ввести где-либо 802.1х с dvlan и ... Закроем дискуссию, ибо она стала уже терминологической есть много L3 switch со встроеным dhcp server.

My WebMoney Linux хранит пароль в открытом виде

Элементарно. Зачем хранить пароль - если можно хранить токен авторизации ? Всётаки огромная разница в безопасности между хранением открытого пароля и всего лишь токена. Который конечно позволит войти без пароля, но это не одно и тоже. Скайп, к стати хранит хэш и токен.

DHCP server hardware requirements

Чем железный роутер отличается от L3 свитча

Ответ для спрашивающего — судя по вопросу L3 свич + DHCP достаточно. дальше читать не нужно.

JDima — я посмотрел Ваш профиль. Смысл вопроса? Пока не нужно всяких AAA, netflow, L7, vpn, BGP, roaming, итп. L3 switch — лучший раутер. Магическое слово «дорого» вполне отбивает охоту.
каким образом это стабильнее и каким образом это снимает необходимость в DHCP?
DHCP протокол получения IP — не снимает, просто это уже будет подзадача связанная с радиусом или другими подобными. Ну и главный момент L3 не умеет дефрагментировать пакеты, никак с помощью L3 не сделаешь проброс в сеть с jumbo frames. Они в принципе предназначены для разных вещей, и более того раутер ни разу не заменяет свичи. Что и кто умеет — это разговор о конкретных моделях, и никак не связан с воспросом. Вот к примеру у меня DLINK раутер валяется в хламе — он настоящий раутер по определению — но для сети больше чем из 10 клиентов — это просто мусор.
Я говорю о общем случае. Несколько лет проработав в cisco академии предпочитаю не привязыватся к brand/model железа в ответе на общие вопросы. Чтобы доступно человеку помочь.

Проброс DHCP (есть несколько способов) будет с проблемами.
А подробнее? Какие проблемы? Вроде используем на многие тысячи клиентов, никаких проблем.

Улетело 2 предложения, как запретить броадкасты — текст удалил. Предложение осталось.

Вообще, главное, что я хотел сказать. Это когда видишь что, в среднем, больше 90% пакетов на порту broadcastы — и это всего сотни 2 виндоз, пару десятков эплов, и не знаю сколько wifi — клиентов (которые естественно практически не работают). То хочется прибить людей, которые придумали эту плоскую сеть… А они тоже обратились с проблемой «нельзя получить IP адрес в Wifi с первой попытки.»

Как вы организуете devel окружение?

rozhik, обьясняю:
0. Вы наверное не сталкивались со словом сборка…
1. администрировать десятки машин разработчиков это…
2. когда нужно показать промежуточный результат в наружу — не проблема. (доступа к к машинам разработчика снаружи нет)
3. когда ключей лежит вагон.
и много других причин. Вообще есть цепочка:
local -> devel -> staging -> pre-production -> production.
local — никого не волнуеи, показать никому нельзя.
develN — можно показывать статус, давать на предестирование
staging — тестеры его проверяют, обновить не каждый разработчик может
…

Безопасность запросов со сторонних сервисов

Опишите детальнее, с примером. Сейчас не понятно о чем вопрос.

Как вы организуете devel окружение?

Этот подход с локальными машинами быстро загибается на больших проэктах.

Как вы организуете devel окружение?

Конечно с репозитариями. У нас как правило каждый проэкт живет в нескольких репозитариях, часть может быть на SVN, часть на git. Без VCS ничего никто не пишет. Сервера у нас не лежат. Даже у дев сервера 99.99% uptime.
На рабочих машинах разрабатывать не реально — особенно с терабайтными базами итп.

«Именные» СМС

Значит, скорее всего это конец.

«Именные» СМС

Проверьте. Но как правило роуминговые потоки не фильтруются. Конечно оператор может сделать с ним всё что угодно.
Тем более я лет 10 уже не имел с СМС дело. Но раньше подобные проблемы решал именно так.

Получить контент внешнего js скрипта

Никак. В памяти или нет — но cross-origin проверка безопасности не даст доступ.

Олимпийский огонь полетел в космос. Что происходит с системой «олимпийский огонь» при ускорении и в невесомости?

Он сам погаснет. (Физику никто не отменял).

Ищу пульт для XBMC

Portable 2 in 1 2.4GHz Mini Wireless Touch Pad Keyboard Mouse Combo for HTPC — гадость редкостная. Не советую. Кнопки расположены не удобно. Из сна иногда выходит несколько секунд. Кнопки L,R (которые мышиные) подглюкивают.

Чат в тяжелом проекте на symfony (в любом тяжелом бэкенд-движке) — как?

Буду утрировать и упрощать:

Допустим, в чате нужна информация о пользователе uid, nick, roomlist.
В симфони, где вам нужно активировать чат вы делаете RPC вызов ноды createChatter( randomStr, uid, nick, roomlist ) (естественно вызов делаете с авторизацией, к примеру по общему с нодой паролю). Сохранили andomStr в сессии симфонии (если еще раз нужно открывать сей чат). И послали пользователя на your-chat.com/auth/$randomStr. В ноде уже есть ассоциация randomstr -> {uid, nick, roomlist}. Всё. Подобрать/взломать почти невозможно (ведь RPC прошел на прямую без участия пользователя). Синхронизировать ничего не нужно. Просто при повторном вызове createChatter с тем-же uid, старая ассоциация разваливается. Остается только новая.

Записывать в базу сообщения не обязательно (они ведь, должны висеть в пямяти nodejs). Но если хотите можно сбрасывать. Мы, к примеру сбрасывали, все новые сообщения в табличку для лога. А moderation-tool, написанный на PHP говорил чату какие сообщения выбросить через RPC. (Чат у нас написан на perl, но нода даже лучше).

Пока я писал этот текст — я бы успел бы написать websocket-чат с такой аутентификацией ;)

Чат в тяжелом проекте на symfony (в любом тяжелом бэкенд-движке) — как?

Их на самом деле много. Перечислю несколько.
1. Чат сервер может стоять как угодно далеко, иметь другой домен итп.
2. Чат сервис может использоваться как отдельная компонента от проэкта, шарится между несколькими итп.
3. Нет зависимости от механизма поддержки сессий другого сервиса (представьте себе забытую вкладку с чатом на месяц).
4. Распределение нагрузки и точек отказа.
…
я перечислил несколько — но легко написать более сотни плюсов ( с минусами у меня фантазия(или опыт) хуже)

Как лучше внести большие изменения в структуру бд?

Потому, что привык обеспечивать SLA 99.99.

Сохранение массива в файл и его чтение

Вот сколько текста, а ведь только букву пропустил.
Всегда полезно варнинги читать о контроле типов. Да и штука .h вайл — очень верная.