Обнаружил в браузере "Управляется вашей организацией". Как убрать?

sso настроить не пытались ?

Как уменьшить прожорливость Apache?

настроить связку nginx+апач

а для каких целей вам именно апач ? Есть конечно вещи, которые он умеет лучше (или вообще просто умеет) чем nginx. Но они, скажем так, достаточно специфичные.

Автоматика для полива?

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

Автоматика для полива?

при таких расходах в качестве 'сенсора' подойдет обычный счетчик воды. Выходящие из него проводочки замыкаются-размыкаются каждый оборот мерного колеса

Что лучше для защиты сети: OpenWRT или pfSense?

PS не является текстовым редактором не потому, что умеет картинки рисовать, а потому, что несмотря на наличие возможности редактировать текст, функционал по работе с текстовыми документами в PS отсутствует.

Внимание вопрос: что из традиционного функционала межсетевых экранов (применимого для домашней сети) отсутствует в openwrt и присутствует в pfsense ?

Что лучше для защиты сети: OpenWRT или pfSense?

А что, netfilter, из openwrt вырезали ?

Как правильно работать с массивами в С?

и где в нем считается сумма элементов расположенных до минимального ?

Есть ли смысл использовать старые точки доступа Cisco?

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

Можно ли снять дамп Oracle без доступов?

Максим Sh, а что вас удивляет ? даже при отсутствии в СУБД интеграции с механизмами снапшотов это дает несколько больше шансов на успех, чем 'просто скопировать файлы'.
А у MS SQL сервера, где такая интеграция присутствует (SQL Server VSS Writer), это в принципе один из штатных механизмов бэкапа.

У оракла под виндой вроде бы тоже есть VSS writer, как под линухами дела обстоят - не знаю. Равно как и какая ось стоит у автора и какие у него к ней доступы.

Почему в __init__ не меняется переменная?

robick231, ну так вы это указали после создания объекта (и выполнения __init__())

Как проверить что по serial пришел полный пакет данных?

это вы про какой последовательный протокол сейчас, позвольте узнать ?

Как проверить что по serial пришел полный пакет данных?

- доктор, у меня что-то болит
- сейчас я вам выпишу каких-нибудь таблеток

еще раз: последовательный порт обеспечивает лишь доставку байтов. за конкретным протоколом обмена с конкретным устройством - читайте документацию на само устройство. C++ как таковой здесь вообще ни при чем

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

не будет работать для udp

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

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

Валентин,
mtu на интерфейсах стримера 1500
размер отправляемых UDP-пакетов вообще 1344 (20+8+1316)
так что, нет, дело не в mtu, увы

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

hint000, это проще в настройках порта свитча делать (и, естественно, сделано)
но это именно костыль, т.к.
во-первых проблема не решается, а (достаточно неплохо) маскируется. burst'ы остаются и на 100Mbps, только гоораздо реже приводят к нежелательным последствиям
во-вторых приставки, имеющие 1Gbps интерфейс помимо вывода IPTV потока еще и другие задачи выполняют, для которых гигабит полезен.

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

ru6ak, видите ли, нынешнее обновление прошивки - долгожданный результат запроса к производителю для решения другой проблемы (которая зажатием порта на 100Mbps не костылится).
В добавок самому производителю на данную проблему пофиг, т.к. его родные STB (китайский OEM ессно) довольно хилые и 100Mbps only. Так что он даже не видит что 'что-то не так' ибо в 99.999% случаев буферизация свитча проблему маскирует, а 0.001% можно и на косяк сети или исходного сигнала списать.

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

В том, что нужно, мы уже более-менее разобрались: нужен pacing для UDP трафика. Вопрос 'как' ?
если б мы могли сами перекомпилировать стримящий софт, то по идее достаточно было бы включить fq на интерфейсе и при открытии сокета в опциях указывать so_max_pacing_rate.
Но на открытие сокета мы, увы, повлиять не можем.
Есть ли вариант установить systemwide умолчания для sockopt вновь открываемых сокетов ?

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

ну так задайте этим клиентам 100М на порту и проблема решена

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

в каких то промежуточных узлах

с чего вы взяли про промежуточные узлы ? к стримеру есть рут-доступ, на нем обычный дебиан.

правильней будет открыть кейс у разработчика

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

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

Вы не понимаете о чем я пишу.
ТВ-канал, приходящий со спутника, представляет собой цифровой сигнал в 10Mbps, причем эти 10Mbps это именно один бит каждую 0,1 микросекунду (это не совсем так, со спутника приходит мультиплекс из нескольких каналов, но для первого приближения и понимания порядка величин вполне подходит).
STB-коробка (а проблемы именно с STB коробками, а не 'конкретным ноутбуком'. И коробок этих на объекте несколько сотен) прекрасно с этой задачей справлялась.
Но как только стример стал слать не 'один бит каждую 0,1 микросекунду' а сначала 200000 бит за 100 микросекунд (100 бит в 0,1 микросекунды), а затем 19800 микросекунд молчать приставки наелись.

И т.к. задача приставки не столько молотить сетевой трафик, сколько показывать TV-поток, а исходный TV-поток творчески обрабатывается сервером до непринимаемого состояния, то проблема в общем-то не совсем в приставке.

Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

Или вы правда вливаете в ноут больше 10 потоков по 10 метров?

Естественно нет. в клиентский порт приходит ОДИН поток в 10Mbps. Другого трафика на порту НЕТ.
Но эти 10Mbps являются 10Mbps только при усреднении на боле-менее длинных интервалах (>20ms). При более коротких интервалах это burst'ы в [почти]1000Mbps, длящиеся сотню-другую микросекунд, перемежающиеся паузами в ~20 миллисекунд. И, как вы совершенно справедливо заметили, клиентское железо с обработкой этих burst'ов не справляется, несмотря на то, что в среднем поток небольшой.

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

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