Существующие в природе датчики объема, движения и присутствия это одно и тоже или это разные по принципу работы железки.

А существуют такие датчики с USB интерфейсом работающие под Linux?

Захотелось сделать жизнь коллегам попроще: сделал web-интерфейс для команд ping и tshark. Online отображение результатов команды делаю через Content-type: multipart/x-mixed-replace; C HTTP частью все нормально. Но возникла проблема с чтением данных из программы. Причем проявляется оно даже на уровне чистого шела.

Если запустить команду:

tshark -n -i eth0 -c 25 host 10.0.0.1

то она нормально все показывает в "live" режиме

А если запустить ее немного подругому:

tshark -n -i eth0 -c 25 host 10.0.0.1 | cat

то вывод команды приходит реже большими кусками.

Тоесть например если из трафика сделать только пинги раз в 2 секунды. То последняя команда будет сначала долго молчать а потом выплюнет сразу 16 строк, потом опять тишина, потом еще 16 строк.

С вызовом ping xxxx | cat тоже самое, но только для случая если xxxx не отвечает - сначала тишина (даже первых строк о том что пинг начался нету) а потом сразу результат. Если xxxx пингуется то отдается результат сразу.

Что с этим можно сделать?

>>>

Я сейчас пишу один проектик, и хочю чтобы можно было легко его локализовывать, причем мне нужна не столько возможность перевести все сообщения программы на другие языки, но и перевести некоторые термины, в зависимости от пожелания заказчика. Впринципе все понятно, умные дядьки придумали gettext(). Соответсвенно программу я пищу следующим образом: все выводы сообщений пишу через вызов функции _(), в коде программы сообщения на английском, и раз в неделю обновляю .po файл.

Все замечательно, но сообщения "Not selected", "Any" (используеться как один из варианты выбора в выпадающих списках) встречаются в программе часто, и в разных контестках, и хочется чтобы на русский передовились как "Не выбран" "Не выбрана" "Не выбрано", "Любой" "Любая" "Любое".

Пока мне в голову приходит только сдедующий варианты: писать в теле программы вместо всех сообщений, некие "пседво" сообщения из которых понятно, что должен увидеть пользователь и в каком контектсе, и делать перевод этих сообщений на все языки, в том числе и на английский.

Либо, специальным образом метить контестно зависимые сообщения, тоесть например вместо _("Not selected") писать _("__Not selected (no file selected)") или _("__Not selected (no group selected)"), и на английский перевести только эти фраза, а остальные не трогать.

Есть ли другие варианты?

Есть сервер, и он постоянно (два раза в день) начинает жутко тупить, помогает только reboot.

Хронолоиня событий: Есть сервер (P4HT-2400MHz,512 RAM), который выполняет функции роуетра+биллинга: у него есть ряд внутренний внешних интерфейсов, с внешним миром связан по BGP (прием только default) с внутренней сетью по OSPF (около 50 сеток с двух других роуетров), сервер делает NAT, shaping (CBQ на внутреннем интерфейсе для индивидуального шейпинга, и TBF на IMQ интерфейсах для массового), фильтрует доступ в интернет (iptables, всего около 5000 правил, то они расписаны по кучи разных цепочкек, так что в среднем пакет проходит черер 100-200 правил), считает трафик (ipfm и ipaudit работают полность параллельно (для подстаходвки)), обробатывает трафик в базе mysql (база в данным момент около гига) и дает доступ к этим данным через web. вообщем задач много но последнии пару лет, он с этим спокойно справлялся. трафик через него 10-20 мегабит (в зависимости от времени суток и дня недели). ядро 2.4.22 c патчем IMQ. load average был 0.5-1.5 основные CPUжрущие процессы - считалка трафика.

Заходтелось немножко новых фишечек, и для этого было собрано ядро 2.4.32 (с kernel.org) + IMQ + pom (захотелось ipp2p, ipset, CLASSIFY, CONNMARK). Ядро было успешно собрано и запущено пару недель назад, и все нормально работало. (новые фишки пока не применялись)

В понедельник днем был заменен TBF на одном из IMQ интерфейсе (трафик до 9 мегабит), на HTB+SFQ (трафик разлелен на 3 очереди, и у кажой свой rate и ceil), все продолжило успешно работать до вечера (когда пощел оснавной трафик), и тут севрер начал торомзить: load average начал расти (до 5-10-15-20-25), считалки трафика жрали все достпное CPU, другие задачи начали тупить (mysql еле отвечал на примитивные запросы, страницы которые раньше генерились за секунду стали генерится минутами), сервер стал тупить к консоле, и на ping стал отвечать с задержками, трафик пропускать стал меньше обычного, пошли жалобы на дропанье сессий). Попытки реанимировать сервер без перезагруки не дали резульатата. (было перезружены все серверис какие только можно (mysql, httpd, считалки трафика, шейперы). В резульате сервер перегрузили, и все стало работать нормально.

Во вторник утром ситуация повторилась, сервер перегрузили, но уже без шейпера на IMQ устройство.

Во вторник вечером ситуация повторилась.

В среду утром ситуация опять повторилась, откатились на старое ядро. Тоесть систему полностью вернули в исходное состояние.

В среду вечером ситуация повторилась.

И сегодня утром ситация опять повторилась.

Обычно считалки трафика (они работают через libpcap) начинали жрать пространство, если в сети бродят вирусы которые массово сканять порты, или генерять левый трафик (spam,DOS и т.п.) и если этот трафик заблокировать (не на этом роутере а раньше) то все нормализировалось Начали анализировать трафик, поствили считалки в iptables первым правилом:

iptables -A counter -i eth1 -p tcp --dport 25 -m state --state NEW (eth1 - внутренний интерфейс)

и начали рисовать график таких правил: заметили что перед тем как серверу начать тупить, поток пакетов срабатывающих на это правило около 5-10 мегабит. тоесть проблема в вируснике. но когда такой трафик исчезает, обычно все входило в норму, а тут перестало входить. Перезагрузки считалок не помогают, считалки работют уже несоколько лет, и подозревать их в утечках памяти схожно.

Все идеи что это может быть кончились, осталось только одно подозрение: в серверной щас проблемы с охлажнением, и там реально жарко.

Вопрос: Как себя ведут сервера в жестких климатических условиях: нормально работают а потом сразу виснут, или сначала тупят? Как себя ведут сервера с битой памятью?

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