Drno, есть версия. На Intel зачастую блокировка возможностей разгона. Нет разгона - нет проблем. Если AMD не разгонять, то тоже никогда нет проблем. Если разгонять, то бывают разные варианты.
Какую-нибудь Asus TUF берите и будет ништяк даже для игр, а для работы тем более.
Смотреть особо не на что, какие-нибудь грабли могут быть только в случае интегрированного Wi-Fi или подобной экзотики (да и то не обязательно). Китайские малоизвестные бренды с Алиэкспресса не брать. А всё остальное просто работает.
pcdesign, действительно, умножение с другой стороны нужно делать:
res = need.dot(m_inverse)
(матричное умножение оно такое, если переставить множители местами, то результат будет другой)
ещё один момент:
need = np.array([100, 50, 150])
первоначально в вопросе было не 50, а 95
для [100, 95, 150] результат будет [[1.94344927 6.05900626 0.22304572]],
для [100, 50, 150] результат будет [[ 1.94292292 6.11540192 -0.2841446 ]], но мы не можем съесть отрицательное количество сала, значит точного решения нет для таких исходных данных.
Li, тогда с командой rfkill поэкспериментируйте, она для выключения\включения модулей Wi-Fi и Bluetooth.
Начните с rfkill list для просмотра текущего состояния адаптера.
В администрировании файловой шары видно, с каких компьютеров и\или какими пользователями открыт файл (хоть под Windows Server, хоть на Samba под Linux).
Там же можно принудительно закрыть. После этого можно и простым копированием бэкапить, если не нравятся теневые копии, которые предложил АртемЪ.
Maxim Siomin, много обсуждений этой темы можно нагуглить, вот цитаты:
https://pc-01.tech/x-264-x-265/
...Всё вышеописанное справедливо только для софтверного кодирования которое имеет лучшие характеристики качества/битрейт. При использовании аппаратного ускорения и кодировании в h.264 и h.265, при возможности выбора динамического битрейта и более высоких значений среднего битрейта кодирование видеокартой будет существенно лучше по соотношению качества/производительности, но хуже по соотношению качество/битрейт.
https://habr.com/ru/post/511512/
Слишком сложные алгоритмы для видеокарты, которые не особо хорошо ложатся на её вычислительную архитектуру. Кодеки под неё упрощены в плане анализа кадров. Качественная картинка только за счет более высокого битрейта. Если сравнивать HEVC на видеокарте простив H264 на CPU (с настроками на максимальное качество), то возможно будет паритет в отношении размера файла и качества. Если же HEVC на видеокарте против HEVC на CPU (настройки на качество), то без шансов для видеокарты. По скорости кодирования да, она будет быстрее.
https://video.stackexchange.com/questions/14656/wh...
AFAIK, this CUDA project didn't pan out. There is support for using OpenCL to offload some work from the lookahead thread (quick I/P/B decision, not a high quality final encode of the frame).
CPU encoding is focused on quality where GPU encoding is focused on speed - if you can accept lower quality or higher final bitrate then GPU encoder will be faster, if your goal is highest possible quality at lowest possible bitrate then CPU based encoder will be closer to your goal at a cost of encoding time.
https://linustechtips.com/topic/1001331-video-enco...
Another thing to consider is quality over speed, CPU: Quality | GPU: Speed. This is another reason most prefer CPU if theirs can handle it that is or they will choose GPU over CPU if the CPU is occupied
Чтобы не ломать голову долго, создайте символьную ссылку на новую директорию. И пусть dovecot себе думает, что он хранит всё по старому пути. ln -s /mnt/vmail /var/vmail
