rPman

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

В браузере прокси не настроена? потому что webrtc игнорирует настройки прокси и работает напрямую

диалоговое окно выглядит стандартно для direct show компоненты настройки видео.

очень странно. что настройка в одном месте учитывается в другом (кнопка по умолчанию?)

Это диалоговое окно можно вызвать из vlc (меню файл - открыть устройство захвата и кнопка Другие или Настройка)

'Хорошие' модели начинаются с 32b qwen, на крайний случай 14b deepseek distilled qwen

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

Напоминаю, тюнинг почти не улучшает знания модели (чаще ломает), и в лучшем случае меняет формат ответа. Помню был пример для 8б модели llama, которую дёшево тюнили на стиль общения конкретных людей в чате, точнее на сам чат

grub наверное является таковым, с поддержкой efi, на сколько я знаю, умеет из себя запускать windows и само собой linux, имеет условно графический интерфейс (вообще то текстовый но можно добавлять картинки)

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

P.s. Гулится что получение списка файлов медленное, и имеет смысл сделать это заранее и сохранить его отдельным ассетом

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

Авторизация аккаунта это еще один, другой метод, который может автоматизировать авторизацию в браузере но не наоборот.

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

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

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

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

Постоянные опросы, это просто некрасиво и да, тут не создаст проблем, ведь делает это только один участник (некрасиво это когда запрашивающих состояние много, тогда нагрузка на сервер взлетает экспоненциально от их количества). Правильно и логично, наладить двустороннюю связь по http rest (сервис В сообщает об изменении в состоянии сервису А вызвав у него соответствующий http запрос) или используя socket (websocket, благо решений готовых тьма, т.е. сервис А держит открытое подключение к В и по нему же отправляет и получает всю необходимую информацию, бонусом максимальная оперативность и информация проблемах на сервисе или со связью, что будет возможно с задержкой при http rest подходе).

Реализация не требует чего то особенного и тяжелого типа RabbitMQ или Kafka (о чем тут все наверняка сразу подумали/погуглили, всего тысячи отчетов всего 8 воркеров)... это задача того же уровня проверки на профпригодность.

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

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

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

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

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

Итого на сервисе В должны быть:
* веб сервер с приложением обслуживающий запросы, синхронизацию расписания, заполнение очереди задач на выполнение, контроль за нодами с воркерами
* ноды с воркерами со своим веб сервером (независим от процесса, выполняющего задачу)
* хранилище логов воркеров (независимое от воркеров) + база данных сервиса для расписания и очереди

Если производительность контроллера (iops) вас устраивает, то без вариантов использовать его. 1gb кеш делает его несравнимо лучше (наверное во всех смыслах) чем софтварный.

Есть куча способов, каждый требует свой метод сокрытия.

Самый простой - по часовому поясу (из javascript в браузере) и приватная вкладка не поможет (есть вроде бы плагины для смены на лету)

Есть webrtc, p2p протокол для связи между разными пользователями (браузерами), он работает по udp и игнорирует прокси, сам факт подключение раскрывает реальный ip адрес (это отключается в настройках браузера)

DNSleak, запросы прокси ваш провайдер сделает на сервер, и тот это увидит и идентифицирует вас (можно указать резолвить dns через прокси)

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

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

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

Если тебе дороги данные, то ничего не делай с диском и неси в сервис.

Каждый раз, когда windows пытается починить диск при сбойном контроллере на материнке/кабеле/плате, она уничтожает данные с большими шансами.

Максимум, нужно убедиться, что проблема именно в диске, для этого диск можно перенести на гарантированно рабочий компьютер (так же sata кабель другой использовать), но по трудоемкости это сравнимо с отнести в сервис и заплатить 200-500р за диагностику.

Лучшая на текущий момент по соотношение качество/цена в задачах программирования это Anthropic Claude Sonnet 3.7, в частности у них заявлен Computer Use for coding, приложение, в котором вы отдаете компьютер под управление модели (подключаемой по api) и командуете ей, и она выполняет команды, смотрет вывод, решает проблемы и т.п.

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

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

p.s. такие эксперименты будут не дешевы.

qpdf например,в командной строке
так же есть imagemagic или gs (ghostscript)

Первая проблема задающих вопрос (не только на хабре а вообще) - это дано недостаточно информации. Из вопрошающих приходится чуть ли не клещами выбивать ее.

Выдавай максимум информации. Что есть, что хотел, как думал решать, как получилось, как не получилось.

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

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