hint000

Просто вычти из "х" значение 69, тогда оно станет равно 54.

Правда, есть ещё одно подходящее значение х, чуть больше единицы, но его найти сложнее.

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

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

Хотелось бы понять психологию крыс, почему им хочется иногда грызть кабели.

Они всё грызут:
1. Зубы стачивают (в основном об твёрдые предметы)
2. Пробуют на вкус (если не хватает еды, ищут что ещё съедобное есть)
3. Сильный голод (если совсем не хватает еды)
В принципе если крыса не голодная, то она не будет экспериментировать с рационом и закусывать пластиком, но если крыса не голодная, то она будет размножаться и у тебя будет уже 10 крыс)

Об отраве речь не идёт - её нужно часто обновлять, дохлятину убирать, да и сами знаете, крысы хитрые и их очень сложно отравить

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

Вообще есть кабели с репелентом непосредственно в массе оболочки кабеля, но стоят они дороже, чем бронированные.
Если не хочется прям весь кабель менять, то я бы предложил загнать его в металлическую гофру и избавиться от грызунов рядом с выходами.

- Купил АДАПТЕР OPENBOX USB DVB-T2/C (MyGica Mini DVB-(T/T2/C) USB Stick T230A).
- На NanoPi R4S установил Armbian 24.8.1 Noble 6.6.47 minimal
- Установил mumudvb_2.1.0-dmo2_arm64.deb из debian-multimedia (в родном старая версия)
- Файл конфига для mumudvb (MUX1 - PLP 1):

freq=546000
delivery_system=DVBT2
autoconfiguration=full
multicast_ipv4=1
multicast_ipv6=0
unicast=1
ip_http=0.0.0.0
port_http=4028
stream_id=1 #PLP=1 Россия 1, Россия 24 и ОТР
#stream_id=0 #PLP=0 Первый, Матч!, НТВ, Пятый, РОССИЯ-К, Карусель, ТВ Центр

- Запускаем mumudvb -d -c config.conf и получаем:

...
Info:  Autoconf:  We update the channel CAM support
Info:  Autoconf:  Diffusion 3 channels
Info:  Autoconf:  Channel number :   0,   service id 1020  name : "02 РОССИЯ-1"
Info:  Autoconf:        Multicast4 ip : 239.100.0.0:1234
Info:  Autoconf:        Unicast : Channel accessible via the master connection, 0.0.0.0:4028
Info:  Autoconf:  Channel number :   1,   service id 1070  name : "07 РОССИЯ-24"
Info:  Autoconf:        Multicast4 ip : 239.100.0.1:1234
Info:  Autoconf:        Unicast : Channel accessible via the master connection, 0.0.0.0:4028
Info:  Autoconf:  Channel number :   2,   service id 1090  name : "09 ОТР"
Info:  Autoconf:        Multicast4 ip : 239.100.0.2:1234
Info:  Autoconf:        Unicast : Channel accessible via the master connection, 0.0.0.0:4028

- на другой машине в сети делаем: ffplay udp://@239.100.0.0:1234
- или VLC: x.x.x.x:4028/playlist.m3u

Соответственно, для получения всех MUX'ов необходимо 5 свистков:
- Первый — частота 546 МГц х 2 Потока
- Второй — частота 498 МГц
- Третий — частота 578 МГц
- Первый HD - 700 МГц (только в Москве?)

Нагрузка на проц при стриме MUX1:

1. Предварительно подписывать документ самому. После получения проверять кооректность всех подписей.

2. Считать контрольную сумму файла перед отправкой и проверять после получения. ( но тогда, скорее всего, потребуется использовать открепленную цифровую подпись и надо где-то у себя хранить контрольные суммы (хэши) для отправленных файлов. )

снимите одну галочку и будет счастье )

(x + 90) * (60 + 240) / (103 + 90) - 240

Нельзя. Thunderbird - это клиент.
Поднять свой сервер гораздо сложнее, чем кажется на первый взгляд. Придётся получить фиксированный белый IP, разобраться в DNS, настроить SPF, DKIM, DMARK. Гораздо проще разобраться, как отправлять письма через SMTP-сервер того же gmail.

Возможно проблема в чистке журнала транзакций (база переводится в simple, shkrink ну и обратно в full), но на другом сервере проблем не наблюдаю с этим.

Да, это как раз может вызывать вашу ошибку: если после полного резервного копирования происходит изменение модели восстановления базы (full->simple->full), и в момент, когда БД находится в simple, происходит усечение журнала транзакций, то цепочка записей транзакций после полного копирования оказывается нарушенной. А если усечения не происходит, как на другом сервере, - то вам везет. Поэтому так, как вы делаете, делать не надо.
Вы сжимаете именно журнал транзакций, а не саму БД, я правильно понял? В таком случае посмотрите, а надо ли это вам. Потому что резервное компирование журнала транзакций очищает занятое место в его файле. И это место в дальнейшем (через некоторый промедуток времени - после переключения на другой логический журнал) может использоваться повторно. В результате в стационарном случае - при примерно одинакой частоте трназакций - файл журнала расти перестает.
Если же вам действительно потребуется сжать журнал - например, после массовй операции типа загрузки большого объема данных - то это можно сделать, не меняя модель восстановления БД. Делается это последовательностью операций "резервное копирование журнала"->"повторное резервное копирование журнала"(лучше после паузы, чтобы преключение на следующий пустой логический журнал, который будет в начале файла, точно произошло)->"усечение журнала с конца"(truncate). Иногда, правда, эту последовательность может потребоваться повторить (если переключения на пустой логиченский журнал в начале файла не произошло).
А усечение журнала трназакций с конца - это очень быстрая операция (потому что никакие записи журнала никуда не перемещаются), так что ее можно делать обычно даже в период номинальной нагрузки, днем.

Докину своих замечаний:

- Всегда делайте макета для FullHD эакрана в 1920px, даже если у вас контент на 1000px, не надо делать макета шириной 1200px, а потому удивляться, что шапка, которая тянется на весь экрана внезапно, увеличилась в размерах на FullHD и потеряла в качестве.

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

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

- Если вам нужен какой-то более-менее стандартный шрифт используйте Google Fonts, это проверенные шрифты, которые гарантированно работают как надо. А использование каких-то аналогов с глубин интернета это, во-первых, может быть не совсем законно, так как шрифт может быть платным и это надо учитывать. Кроме того, если в дизайне вы используете допустим только ttf, то для web это все надо конвертировать в другие форматы, что может принести проблемы и как итог в верстке шрифт выглядит совсем иначе.

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

хочу знать, где верстальщик ленится

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

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