Алексей: зачем консольный? Мы же иксы запускаем, и уже из под них графический интерфейс. Можно из этого скрипта запускать, например, mpv или mplayer. Т.е. видеоплееры, которые легко запустить в fullscreen режиме без видимых элементов управления.
Аналогичным образом делаются, к примеру, web-киоски -- там браузер запускается. Ключевые слова для поиска -- "raspberry pi web kiosk".
Тут важно понимать:
X11 -- это графическая подсистема. Она занимается отображением окошек, но сама не в курсе даже где эти окошки на экране размещать -- как приложение попросит, так и разместит.
WM это та штука, которая уже управляет окошками. Рисует элементы интерфейса для них, понимает различные команды клавиатуры/мыши для изменения размера и расположения окон, их закрытия, и т.д. В Linux это необязательный элемент системы. И в комплекте к этим WM обычно идут отдельные (!) приложения для отображения всяческих тулбаров, tray icons, рабочего стола. разных настроек, меню, и т.д.
DE это штука, которая содержит в себе WM и какой-либо еще инструментарий, объединенный в единое целое.
Для работы графических приложений всяческие WM и DE не являются необходимостью.
Я правильно понимаю, что задача -- запускать некие скрипты в моменты заката и восхода?
Хранить данные лучше не в переменных окружения, а в файлах.
Например такое решение: создать каталоги /etc/cron.sunset и /etc/cron.sunrise. Далее тот код, который вычисляет (или где-то берет) время заката/восхода запускается ежесуточно из cron'а, создает файл /etc/cron.d/sun, в котором будет указано запускать все скрипты из этих каталогов в соответствующее время. После чего этот же код выполняет /etc/rc.d/init.d/crond reload.
Если вы таки опишете что именно и как вы собираетесь таким образом запускать, может быть я смогу подсказать еще лучшее решение.
1. Ну например начиная с 1.6 там можно ставить фильтры обработки голоса :) Проигрывание музыки в линию, конференц-связь. 3-х сторонные конференции, и прочие радости жизни. Это-ж офисная АТС, там много мелких фич. Да даже трансляция DTMF из inband в более человеческие форматы.
Напомню, что для астера SIP всего лишь один из channel modules.
2. На 1.6 не проводил тесты. Но, насколько я знаю архитектуру, сомневаюсь что они это исправили. Другое дело, что после установления соединения, если это SIP2SIP без опций обработки DTMF, то тред передаст соединение rtp-движку, и вся обработка rtp будет в рамках одного треда AFAIR.
В старых-то версиях еще прикольнее было, каждый RTP пакет сначала разбирался во внутренний астерисковский формат фрейма, а потом собирался заново. Это только в 1.4 они сделали вообще отдельный rtp-движок, который при прямом соединении без транскодинга тупо менял таймстампы в rtp и передавал его дальше.
Разработчики идиотами не являются, но пишут продукт явно несколько сложнее своей компетенции. Вы в исходники посмотрите, особенно в исходники chan_sip. Который, фактически, один человек писал. Перед просмотром не забудьте взять рвотный пакетик и успокоительное — понадобится.
На самом деле я восхищен тем, что ЭТО умудряется как-то работать. И дедлочится всего лишь при некоторых конфигурациях, а не постоянно (на тамошнее использование локов смотреть настоятельно не рекомендую — успокоительное не поможет, и может потребоваться срочная психиатрическая помощь).
Но таки при всей своей ублюдочной архитектуре оно работает. И ничего столь же активно развивающегося и поддерживающегося нет. Все форки благополучно сдохли, из живых конкурентов астеру только freeswitch. Так что мыши плачут, колятся, но кактус жрать продолжают — пляшем с бубном и в каждой конкретной ситуации добиваемся его работоспособности.
В том-то и дело, что циска это роутер. И если не пытаться вмешиваться в голосовой поток и делать всякоразную странную логику (для чего собственно и предназначен астер), то никаких проблем в передачи 400 голосовых соединений нет. Потому как 400 голосовых соединений, это всего лишь 20k pps, в которых надо тупо переписать несколько байт в RTP пакетах.
Собственно потому какой-нибудь OpenSER на современном оборудовании обработает тысячи соединений и не пискнет.
А астер, напомню, на эти 400 соединений еще и создаст по треду на каждое, и будет заниматься большую часть времени переключением контекстов вместо работы :) На железе аналогичном той самой кошки астер бы еле-еле шевелился, и с трудом бы передал несколько одновременных соединений.
Астер это не софтсвич, и не SIP-proxy. От этого есть свои преимущества (фичи, невозможные для SIP proxy), и свои недостатки (по сравнению с любым SIP proxy астер это не тормоз, он якорь).
Собственно потому до времен 1.4 все, кому нужен был большой трафик (операторы), старались использовать астер в связке с OpenSER. Где коммутация делается средствами OpenSER, а всякие фичи — коллцентр, интерактивные услуги, и т.д. — на астере.
Собственно о чем мы говорим? Задача вполне реальная. И на астере, используемом топикстартером вполне решается.
А мы тут на первоначальный вопрос-то так и не ответили :)
Лимиты на количество исходящих одновременных звонков у оператора определяются во-первых его физическими возможностями (небольшой оператор использующий собственное приземление через E1 может физически не иметь столько каналов). Плюс от ценовой политики (некоторые операторы дают анлим исходящие по некоторым направлениям — ясное дело за слишком активное использование будут бить по голове).
Вопрос решается таки разговором с самим оператором.
Сравнивать циску с астериском некорректно — софтсвич и многофункциональная офисная АТС сильно разные вещи. С точки зрения софтсвича у астериска на редкость ублюдочная архитектура — я код читал, и во время 1.0.* активно патчил, так что в курсе :(
Циску корректнее сравнивать с OpenSER — на котором тысячи одновременных вызовов не проблема.
С факсами, опять же, хочу напомнить что еще во времена 1.4 поддержка T.38 была кривая до безобразия. В 1.6/1.8 ситуация улучшилась, но все же с T.38 проблемы бывают. И в реальности часто приходилось гонять факсы таки в виде медиатрафика. У меня это еще в 2004-м на астере замечательно работало (в те времена поддержки T.38 там не было вообще).
А вот с логами вы правы — это частая причина затыков у астера. Перегруженная дисковая подсистема приводит к тому, что весь астер раком становится.
Но тут еще есть одна проблема — жалуются-то единицы. А их техподдержка не имеет права читать почту своих клиентов. По вашему же письму невозможно определить не является ли его текст подделкой — цифровой подписи-то нет. Да, части хидеров остаются у них в логах наверняка (from/to/message-id). Но вот тело — если и сохраняется, то читать чужую почту права они не имеют.
Соответственно, если бы жаловались все — то они могли бы отключить пользователя на основании массовых жалоб. А жалоба одного пользователя это может быть и просто месть конкурента, например.
Так что с точки зрения оператора, при единичной жалобе вообще-то разумнее спустить все на тормозах, для собственной же безопасности. Или втихаря подглядывать в чужую почту, чтобы проверить что ваше письмо не подделка.
Извиняюсь, я не прочитал «лог разговора».
Это очевидная некомпетентность того сотрудника их техподдержки, с которым вы вели разговор. Похоже он как раз что такое quoted printable не в курсе :)
Можно сначала поинтересовался ФИО этого конкретного сотрудника техподдержки, а потом попросил бы его спросить у коллег из админов что такое 'quoted printable' и почему вы все-таки правы, а он — нет.
Если не поможет — распечатка письма + лог переписки + письмо с разъяснением, и уведомлением что в связи с нежеланием компании бороться со спамерами (а значит явным нарушением сетикета) вы будете вынуждены опубликовать эту историю на блогах/форумах с просьбой перепоста. _Бумажное_ письмо с описью на имя техдира компании. У любого манагера на бумажное письмо с описью стойкий рефлекс — разобраться немедленно и оторвать голову всем виновным и причастным :) Правда есть у такого решения и недостаток — z я не знаю является ли рассылка спама сейчас преступлением, и если да — то после такого письма они могут слишком сильно зашевелиться, и обратиться в соответствующие органы. А тогда вам устроят тягомотину общения с этими самыми органами.
Как обычно, имея дело с некомпетентным человеком: либо вежливо дать ему понять что ему следует обратиться за помощью к коллегам (так чтобы он таки поверил и обратился, а не послать), либо настучать начальству. Остальное уже вопрос формы реализации.
git не может не смотреть на время модификации, потому что иначе git status внутри репозитория с ядром потребовал бы сравнить сотню мегабайт файлов (вернее посчитать для них хэш).
Если дело в правах, то поможет git config core.filemode false
Только майкрософту никто не мешает в случае если этого абонента надо послушать — попросить его весь трафик слать таки на их сервера. Опять же, реализовано это или нет — неизвестно, но техническая возможность это организовать у них есть.
Парсинг html для перловика средней руки это 1 рабочий день — если он был пьян, а ваши верстальщики и разработчики невменяемые идиоты, которые делают ужасный код, и часы, а то и минуты если он трезв, и ваш html код более-менее вменяем.
Так что вы вложите в попытки обфускации много ресурсов, а вскорют ее за 1 день, или пару сотен баксов на фрилансерском сайте.
Никакого технического способа определить кто на той стороне — хакер или честный пользователь не может быть в принципе. Выдадите сертификат — чудесно, этот сертификат и используют в боте. Любые подобные меры тривиально обходятся.
Максимум что вы можете сделать — создать мелкий геморрой, не давая доступа к API тем юзерам, которые не оплатили, а также лимитировав количество запросов с одного IP. Но все это все равно проблему не решает (про историю с аськой все отлично тут уже сказали)
Именно так.
Но для построения масштабируемых систем сейчас все-таки разумнее применять fastcgi и http в качестве протокола. Это позволяет легко отделить фронтенд и раздачу статики от application server'ов. Такая архитектура гораздо проще проще масштабируется (сегодня это дешевая виртуалка где-нибудь, завтра — будет кластер из десятка серверов).
Берем и сравниваем с образцом (образцы можно получить усреднением кусков капчи, которые нам показали — надо собрать заранее). Скажем у буквы 'a' в этом месте должна быть белая точка, а в реальности либо белая, либо черная. Для каждой из версий (можно с учетом смещения) пишем количество ошибок. У кого меньше ошибок, то и наша буква.
Плюс часть зашумления предварительно можно снять фильтрами.
Это за первое приближение алгоритма вполне покатит. Дальше можно дорабатывать. Если нет нелинейных искажений, да еще и мало шрифтов, да еще и нет поворотов под разными углами — распознать никаких проблем.
При таких объемах хотя бы минимальная избыточность необходима. Уж слишком велика вероятность отказа.
А glacier достаточно новая штука, о ней пока не многие знают. У него есть один недостаток — данные для чтения доступны _не_ on-line. То есть при необходимости прочитать, через API делается заказ, и в течении какого-то времени данные будут перемещены в доступное на чтение хранилище.
Аналогичным образом делаются, к примеру, web-киоски -- там браузер запускается. Ключевые слова для поиска -- "raspberry pi web kiosk".
Тут важно понимать:
X11 -- это графическая подсистема. Она занимается отображением окошек, но сама не в курсе даже где эти окошки на экране размещать -- как приложение попросит, так и разместит.
WM это та штука, которая уже управляет окошками. Рисует элементы интерфейса для них, понимает различные команды клавиатуры/мыши для изменения размера и расположения окон, их закрытия, и т.д. В Linux это необязательный элемент системы. И в комплекте к этим WM обычно идут отдельные (!) приложения для отображения всяческих тулбаров, tray icons, рабочего стола. разных настроек, меню, и т.д.
DE это штука, которая содержит в себе WM и какой-либо еще инструментарий, объединенный в единое целое.
Для работы графических приложений всяческие WM и DE не являются необходимостью.