rPman

определить тип DE:
echo $XDG_SESSION_TYPE
для wayland:

gsettings set org.gnome.desktop.interface gtk-enable-primary-paste false

для x11...

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

Если использовать https://platform.openai.com/docs/api-reference/res... и соответственно https://platform.openai.com/docs/api-reference/con... то там сохранение контекста встроено и не требуется пересылать весь контекст каждый раз.

покупаете android планшетник, затем настраиваете удаленное управление на какую-нибудь ред-ос машину-сервер (тот же x2go или еще с 5-6 средств удаленного доступа) и пользуетесь любой программой.

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

пакет tzinfo (штатно идет в linux со всеми дистрибутивами), а вообще данными заведует IANA, вот ссылка

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

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

Для общения вообще достаточно клиентского шифрования с хранением ключей у клиентов и использованием публичных серверов stun/turn и signaling для старта webrtc. Т.е. для создания защищенного чата вообще достаточно статичных страниц github pages (там и исходники можно проконтролировать) и пользователи при создании комнаты должны обменяться по какому то каналу информацией об используемых stun/turn/signaling серверов (есть публичные, можно взять в аренду, можно поднять свой), при этом на практике почти ничего плохого владельцы stun/turn серверов сделать не могут, правда есть проблема с signaling сервером, его владельцы могут селать атаку MITM но второй уровень шифрования на стороне клиента (штатно webrtc уже шифруется) нивелирует эту проблему.

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

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

Крупный бизнес вводит метрики оценки качества работоспособности работников KPI, работники взламывают эти метрики, например попытка оценить качество работы через количество кода, количество закрытых задач в трекере, количество коммитов в репозитарий и т.п.

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

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

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

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

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

hard reset вернет прошивку, установленную 'продавцом', хочешь убрать все лишнее - ищи глобальную прошивку исходного устройства (или совместимого)

погугли: PyVideoTrans, Subtitle Sphere, SoniTranslate

Используешь xpath, это мощнейший инструмент работы с xml, считай regexp но в мире xml, так и пиши сразу

$t=$xml->xpath("//prices/default/price[currency='{$currency}']/price");
$price=(string)$t[0]; // обработать ошибку если count($t) будет 0

{$currency} это наименование валюты в currency, можно прямо константой написать или в моем примере брать из переменной

не нужно ждать интервалы времени, это абсурдно и неправильно!

на windows официальный способ через directx 11 (windows 8+)
https://learn.microsoft.com/en-us/windows/uwp/gami...
примеры гуглятся отвратительные включая msdn, но ИИ выдает их в сжатом и понятном виде:

IDXGISwapChain2* swapChain2; // должен быть получен через QueryInterface
swapChain2->SetMaximumFrameLatency(1);
HANDLE hWaitable = swapChain2->GetFrameLatencyWaitableObject();

// основной цикл
for (;;)
{
    // ждём, пока можно обновлять кадр
    WaitForSingleObjectEx(hWaitable, INFINITE, TRUE);

    RenderFrame();
    swapChain2->Present(1, 0);
}

p.s. еще есть фича монитора (и соответственно видеокарты) nvidia g-sync и amd freesync но это сугубо внутренняя ведь видеокарты, она меняет время обновления монитора в угоду приложения (т.е. не ты ждешь а тебя) но управлять этим напряму не получится... она включается по команде swapChain->Present(0...); (если 1 то использовать v-sync), лично сам никогда этим не пользовался, в жизни только один раз писал приложение синхронно vsync и это было давно и работало коряво (но это проблема была во времена winxp-win7 сейчас с этим лучше).

сам считаю что g-sync это отвратительная фича в той форме что преподносится... для приятных ощущений fps должен быть стабильным, и не обязательно бесконечно большим.. после 60Hz начинаются артефакты уже оборудования (дешевое оборудование и тут уже глючит), и только дорогие mid-end и выше мониторы (это от 50т.р. есть дешевле но там другие проблемы) позволяющие в некоторых случаях эту частоту поднять но артефакты будут, их просто не видно невооруженным глазом. Если же постоянно подруливать частотой обновлений, то эта нестабильность будет сразу заметна и создавать ощущение 'тормозов', вынуждая повышать fps что бы это убрать.

Очень небольшой класс игр требует частоты выше 60, а если честно, подавляющему большинству хватит 40 (кто то скажет 30 но там нужно править видеоряд, добавляя смазывание, что создает другие проблемы)... Посмотрите на эти тесты https://testufo.com/ (не всякое железо в браузере позволит выше 60Hz обновлять но если позволит, рекомендую посмотреть)

g-sync позволит изменить частоту разрешения монитора до требуемой без изменения видеорежима, но на практике в игре в лучшем случае будет выбор 30..60..10500Hz а не число по желанию.

Повторюсь, важна стабильность, любое отклонение от нее воспринимается как тормоза.

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

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

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

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

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

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

например при обновлении/добавлении данных (можно и на тригере), писать в специальную кеш-табличку с одной строчкой идентификатор (или всю строчку данных) последнего элемента, если речь идет о БОЛЬШИХ данных, этот вариант эффективнее в разы (по индексам - N*log N а тут константа, с ценой константы на запись).
если условие выбора вариативное, в кеш таблицу можно запихивать не одну строчку - а варианты по paramname, paramvalue и source (в этой кеш табличке индексы по этим полям уже нужны, но таблица будет маленькой).

достоинства - скорость и возможная экономия памяти (не нужен индекс в принципе для этой задачи или не требуется autoincrement для id, т.е. метод совместим с партицированием в т.ч. самодельным, но тогда в триггере проверять кешированную date и обновленную на случай гонок разных партиций на порядок записи в кеш), это может быть очень критично при БОЛЬШИХ данных.

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

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

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

x86 же на базе какой-нибудь mitx/micro-atx материнки со встроенным процессором intel celeron J4xxx j6xxx и гигабитными сетевухами (подобрать по деньгам) может и 4гбита прожевать, даже usb вариант может оказаться лучше чем специализированные железки, особенно когда считаешь деньги. Потребление таких железок 15ватт у процессора плюс периферия, и размеры там в основном из-за требования по поиску atx питания (они есть но не такой хороший выбор как с большими) и красивого корпуса.

Так как это x86 платформа, там и памяти можно 16гб (вроде бы старые был захардкоженный лимит в 8гб но вроде бы последние модели убрали) или даже все 32, и задач можно повесить больше чем роутер.

сайт с которого скачивать - это файлы статикой, быстро оптимально просто.

проблемы, которые собственно и приходится решать долго нудно и готового все в одном скорее всего не найти:
1. защита от автоматизации скачивания, как только у вас есть простая ссылка для скачивания, ваш сайт станут использовать как хранилище, и вам это не понравится
2. защита от ddos, конкуренты не дремлют, а сетевой трафик один из самых дорогих именно для мультимедиа сервисов
3. защита от 'защитников' авторских прав, она вобще больше в юридической плоскости но есть такие что решают это полутехническими методами, бегодня по доменам и юрисдикциям, AI генерация, приватные загрузки и т.п.
4. сайт это в первую очередь бизнес, и только потом техническая часть (фреймворки, конструкторы), его нужно рекламировать, обслуживать, решать проблемы с оплатой, возвратами, судами и т.п.

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