Интересная статья, но было бы интересно почитать не только про планирование, но и про финальные стадии процесса.
Как оцениваются результаты по итогам?
Как делается релиз или CI?
Что происходит если задача не укладывается в запланированный срок по времени (например, нашелся фатальный баг в используемой библиотеке или что-то такое)?
Как планируются зависимости (по порядку и slack) задач? Например, процент «провала» посчитанный по количеству может быть высок, а из-за slack это на текущую итерацию не влияет на самом деле, что тогда?
На веб-сервере, особенно многопользовательском, действительно обычно превосходит. Есть удобные limits и sa. Есть security.bsd.see_other_uids, не позволяющая смотреть на чужие процессы в top/ps. Есть accept-фильтры. Есть sendfile. И т.д.
Собственно, для SIP вот такие вот большие операторы вообще не нужны, можно организовывать корпоративные (или домашние :-)) SIP-серверы (в привычной терминологии - мини-АТС). И процесс уже вовсю идет.
Как оцениваются результаты по итогам?
Как делается релиз или CI?
Что происходит если задача не укладывается в запланированный срок по времени (например, нашелся фатальный баг в используемой библиотеке или что-то такое)?
Как планируются зависимости (по порядку и slack) задач? Например, процент «провала» посчитанный по количеству может быть высок, а из-за slack это на текущую итерацию не влияет на самом деле, что тогда?
У нас и РИМ-Телекома и одинаковых услуг то нету, какая тут может быть конкуренция? :-)
В Linux (и OpenSolaris тоже, AFAIR) есть значительно более прогрессивный Xen.
http://www.parser.ru/hosters/