mithraen

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

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

100% утилизация процессора на сервере вообще это зло. Особенно для realtime задач (к коим относится и IP-телефония).

С факсами — согласен, тут все уже зависит от задач. Когда делал крупные системы для офисов, факсы обслуживались отдельно (вплоть до подключения к отдельным шлюзам, которые напрямую связывались с оператором).

Но более 900 одновременных соединений в 1 сервере я успешно делал. Жалоб на качество связи при этом не было.

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

К счастью телефония прекрасно кластеризируется.

Конкретно в исходной задаче решение очевидно — зажать G.729 как требуемый кодек для всех peer'ов (потому как все транки обычно умеют его, но не все умеют G.711) — тем самым избавиться от транскодинга. Думаю даже transfer работать под такой нагрузкой будет, хотя надо проверять.

Если понадобится запись переговоров (а она наверняка в call-центре понадобится), вот там будет засада — ибо 400 потоков записи на диск убьют дисковую подсистему напрочь. Так что писать придется на tmpfs, а потом переносить одним потоком на диски. Кроме того писать придется прямо сырой G.729, а чем и где его потом перекодировать в пригодный для прослушивания формат — отдельная песня.

В общем ничего нерешаемого тут нет. Это задача — непростая, требующая подбора оборудования, тестов, и т.д. — но вполне решаемая.

Не слушайте теоретиков. 400 одновременных линий на астере не проблема, но только если нет transcoding, и обработки голосового потока на стороне самого астериска.

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

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

www.voip-info.org/wiki/view/Asterisk+dimensioning — почитайте это. Тысячи одновременных соединений для астериска на современном серверном железе уже не проблема.

И стоит помнить, что между major versions у астериска были существенные улучшения в производительности.

Чисто юридически — могут. В реальности зависит от адекватности конкретных людей.

Skype отказался от p2p, пруф: arstechnica.com/business/2012/05/skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft/.

Так что голос весь ходит через их сервера, где они могут делать что хотят. Делают ли прямо сейчас никто не знает.

Посмотрите на время последней модификации файлов — как оно выглядит на сервере, и как на «смонтированной папке».

Для того чтобы выполнять скрипты, web-серверу нужен некий протокол, чтобы взаимодействовать с этими скриптами. Таковых есть несколько:
— CGI
— FastCGI
— обычный HTTP
— встроенные в сервер API (для подключения модулей — как mod_perl и mod_php в апаче, или встроенная поддержка perl в nginx)

Такое я не отфильтрую. Глазами — тоже.

При таких искажениях поворот уже не нужен, IMHO. Вот это разбирать уже непросто.
Но теперь действительно и читаемость человеком резко упала.

Кстати, большая часть этих точек на картинке элементарно убирается простейшим фильтром (если рядом с точкой есть >6 точек одного цвета — присвоить этой точке то же значение).

При желании это взломать вполне можно — только сначала надо будет набрать базу примеров. Но ничего принципиально сложного в ней нет. Хотя добавленный шум очень усложняет задачу, но вот фиксированное положение букв относительно друг-друга и отсутствие поворотов — задачу резко упрощают.

Это декодируется с помощью Encode::MIME::Header.
Кроме B (base64) может еще быть Q (quoted-printable).

Сделать ограничение, которое вы не сможете сами же сломать не получится. Так что проблему придется решать не техническими мерами, а психологическими.

Вы усложнили себе задачу.

В этой задаче цепочки передачи денег не имеют смысла — они не уменьшают количество транзакций. Скажем у A и B баланс отрицательный, у C — положительный. A может передать деньги B, чтобы он передал C все одной транзакций, а могут передавать их каждый сам напрямую C, от этого ничего не изменится.

Поэтому мы можем считать что нет никакой сети, у нас есть отправители денег (те у кого отрицательный баланс) и получатели (те, у кого он положительный). Каждый отправитель должен послать деньги одному или нескольким получателям.

Я бы предложил простой алгоритм, хотя доказать его оптимальность я не могу:

1. Ищем есть ли у нас пары получатель/отправитель с одинаковым по модулю балансу. Если есть — прекрасно, делаем платежку и обнуляем их балансы (забываем про них).
2. Находим того, кто должен больше всех (отправитель)
3. Находим того, кому должны наибольшую сумму (получатель)
4. Делаем платежку на сумму, наименьшую из этих двух (если у нас есть отправитель который должен суммарно 20, а самый крупный получатель должен получить 11 — делаем платежку от отправителя к получателю на 11)
5. Повторяем, пока не останется ни одной задолженности

aws.amazon.com/glacier/pricing/ — 120$/Tb/год.