Vitalisstico, разрешение и блюр - это отличные друг от друга вещи. Блюр - следствие выставленного дробного (125, 150, 175) масштабирования. При 100% или 200% блюра не будет.
Ну и конечно же, если стрим в разрешении 1080p, то он на мониторе 4k не станет стримом 4к. Но опять же - блюрится он не должен.
Sienore,
Я бы не стал ничего делать без наличия бэкапа.
Поставьте на чашу весов стоимость покупки дисков или одного диска (какой-нибудь HDD на 10 TB стоит порядка 30 тысяч рублей), на другую чашу весов положите стоимость данных на вашем массиве.
Закон Мёрфи никто не отменял.
Zzzz9, мой случай наверное нельзя считать релевантным, но около 10-ка RDP-серверов в диком интернете работают по такой схеме лет 5. Проблем, связанных с брутфорсом rdp, не было. Они все в датацентрах, правда, поэтому, возможно, каналы защищены.
Поэтому самое простое - это сделать смену порта. И дальше ждать инцидента, если случится. В общем, решать проблемы по мере их поступления.
Rish13, если при выключенном файрволе у вас с зумом всё в порядке, значит проблема гарантированно в том, что вы не правильно настроили свой микртик. Смотрите логи дропов/реджектов, как написали вам выше.
Ziptar, предположения можно строить практически бесконечно. В том числе и что у ТС аплинк до 10 мегабит/с.
Какому-нибудь rb750gr (с аппаратным ускорением ipsec), который стоит 10 тыр, размером и весом, как две пачки сигарет, и проживет минимум 7 лет, альтернатив нет.
Если речь про облачный VPS, то тут linux, но хотя тоже можно рассматривать в зависимости от условий.
Денис Юрьев, речь про дробное масштабирование (fractional scaling)- с точкой: 1.1 ; 1.25 ; 1.5 ; и так далее.
Математика (точка в значении, сиречь деление) нагружает встройку.
Суть комента: нужно иметь в виду, что дробное масштабирование может повлечь расход батареи. Плюс многое зависит от "иксы или вэйланд". Если второй - то там еще сами приложения могут не работать с дробным масштабом.
Спасибо за ответ!
Вопрос я не корректно задал. Пытался максимально упростить, чтобы он воспринимался легко, а в итоге после ковыряния вчера ночью стакоферфлоу, понял недостаточность вопроса. И без деталей не обойтись.
В общем, по сути это не лог-файл.
Цель - видеозапись с помощью ffmpeg с монитора при входе пользователя. Задачу создал в "Планировщике задач". выполнение команды:
Внутри grabscreen.ps1 - ffmpeg бла бла бла.
Да, включил "Прибивать текущую" .
В целом всё окей. Экран пишется. Задача перезапускается каждые 5 минут. Прибивается старая задача. Но единственный момент, что во время входа пользователя и перезапуска задачи на доли секунд появляется и исчезает окно powershell. И судя по вою на стаковерфлоу этой проблеме много лет. И уже даже создали на гитхабе некий порт pwshw, в котором этого "мигания" окна нет:
Но собирать его на винде, я не знаю как. И почему-то подозреваю, что если окунусь в его сборку, то вылезут еще какие-то "кирпичи".
Также, нашел что мою задачу можно реализовать через vbs скрипт, а не через powershell. Но там я подвис, ибо совсем далёк. Да создал vbs. Повесил в шедулер. Но каждые 5 минут процесс ffmpeg создается, а старые не прибиваются. Понятно, что vbs скрипт не running, а единожды выполняется и забывает о себе, в отличие от powershell-фонового-задания. А как старый ffmpeg прибить, он не знает. Чтобы знал, я так понимаю, это надо что-то типа поиска процесса по имении и убивать его. Но опять же всё это уже для меня из серии высшего пилотажа.
Мысль, что можно внутри пауршелл сделать цикл типа do { ffmpeg бла бла бла sleep 600 } while, меня тоже не привели к успеху. Потому что ffmpeg - это по сути "бесконечный" процесс.
Нет ли возможности внутри ps скрипта сказать ему что прерывать ffmpeg каждые 5 минут и запускать заново через for или как-то еще?
Рекомендую выбрать в качестве управления сетью systemd-networkd (в противовес Netctl, NetworkManager).
Грубо говоря, это теперь нативный юнит для любого современного дистрибутива линукса и везде одинаково настраивается. https://wiki.archlinux.org/title/Systemd-networkd
Adamos, вы зачем-то постоянно уходите от конкретики и уводите с каждым коментом разговор в абстракцию, то язык не тот, то я в среде гиков. Всё общими фразами, патетикой про Вашу реальность и неким менторским тоном почему-то, не возвращая себе ваше же фразы про "хвалите своё болото".
Еще раз: Арч не менее стабилен, чем убунту! Проверено! Я уже привел наглядные примеры, в том числе из опыта. Вы ограничиваетесь высокопарной лирикой, уходя в какие-то свои размышления на грани эффекта даннинга-крюгера.
У арча есть вики, лучше которой на данный момент нет ни у кого, разве что у коммерческого редхат. Пользователю арча с первого же погружения рекомендуется при проблемах (редких, еще раз говорю из личного опыта) после обновления сразу идти на офсайт в раздел новостей.
Вы без фактажа занимаетесь демагогией, не более. И раз в 4 года своим клиентам переустанавливаете убунту.
Adamos, давайте, Вы сначала честно-честно напишете, что вы видите в заголовках,. кроме того, что там написано. "после обновления в стабильнейшем и монолитном релизе сломался звук". Мы же про стабильность тут чешем.
Какой язык? Если новичок не умеет понимать текст на английском или хотя бы воспользоваться встроенным в браузер переводчиком, то тут уже ничего не поможет - ему не надо в linux-world. Так уж сложилось, что без базовых знаний английского, он вернётся на винду. Молодёжь, кстати, сейчас процентов 50 вполне даже разговаривает с 500 словами в своем активном словаре. Это не наше время в 90-х. И к вопросу о стабильности ОС не имеет никакого отношения, сорямба.
shurshur, Вы меня как будто не слышите :) и продолжаете теоретические выкладки в отсутствии hands-on опыта с современным арчем. Вероятность поломки у него нисколько не выше, чем вероятность поломки в убунту. Сюда еще добавить, что в арче KISS, в отличие от вендор-скриптов и wrap-ов убунту или дебиан. И для нового пользователя в этих дистрах тоже надо будет погружаться в поиски возникающих проблем, достаточно пройти на офсайт убунту. Дебан, не спорю, вылизан, но на момент выхода его новой версии, ПО у него уже старое. В 9 или 10 версии, не помню, было очень критично для производительности, когда virtio-blk отсутствовал в ядре 4.10, когда уже весь мир юзал 5, и для nvme дисков ты ставишь virtio-scsi , производительность которого в разы меньше virtio-blk.
Но да, давайте оставим спор. Было сказано достаточно, чтобы это осталось в качестве мнений для ТС и будущих читателей-новичков в этом вопросе. Дальше только беспощадеый холивар светит.
Спасибо! Ваше мнение, не ставлю под сомнение.