rPman

но раньше спокойно работали

т.е. поломали с каким то обновлением?

Ищешь версию iso образа установки windows не новее того момента когда все работало, устанавливаешь ее (обязательно отключив интернет), ставишь драйвера на видеокарту и по одному устанавливаешь обновления (список обновлений получай с помощью ntlite) до тех пор пока драйвер не перестанет работать

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

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

Echo не умеет выводить массивы, воспользуйся какой-либо сериализацией, json_encode или var_dump или вместо echo используй print_r

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

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

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

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

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

Скорее всего ты не можешь безопасно заблокировать прошивку.

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

Все очень зависит от особенностей задачи, объема данных, требований к непрерывности и т.п.

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

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

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

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

* частный случай с предыдущим - перенести базу данных в оперативную память. sqlite работает в ней невероятно быстро (пример реализации, машина останавливается, у провайдера создается новая с тем же диском но большей оперативной памяти, выполняется нужная работа, временная машина удаляется, диск остается).
Как вариант - у меня был эксперимент, на ram диске соседней машины создавался образ файловой системы, этот файл публиковался с помощью nbd (это как iscsi только проще и быстрее), монтировался уже на целевой машине и туда переносилась база данных, это было во времена hdd и давало очень значимый прирост (вместо часов работы - минуты), теперь с ssd такой разницы можно не получить или для этого потребуется быстрее сети, не гигабитные), сразу скажу что сетевые файловые системы типа nfs/samba не рекомендуются, так как привносят кучу накладных расходов из-за возможности немонопольного доступа и просто из-за особенностей реализации (например fflush на nfs сильно замедляет работу по сравнению с локальной, так как работает по разному)

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

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

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

Учесть занятость машины и запустить на ней задачу - вопрос нескольких строк кода.

Например: в linux есть утилита parallel, ей просто даешь список команд в виде текстового файлика, а она их запускает параллельно с указанным количеством одновременно запущенных процессов, по завершению одного тут же запускает следующий. Никакого контроля за работой нет (т.е. ошибки обрабатывать самостоятельно). Соответственно, настраиваешь беспарольный ssh на машины в сети, затем генерируешь текстовый файл где каждая строка вида ssh случайный_сервер команда и отдаешь его parallel с указанием количества машин -j N (на самом деле если задачи занимают только один поток и на одной машине можно их несколько запускать, то нужно будет посчитать сумму потоков, в этом случае все сложнее, ведь современные процессоры уже не дают линейного увеличения от количества ядер даже в идеальном случае, потребуются бенчмарки). Этот подход не идеален но максимально простой. В качестве развитие этого - список команд генерируется не заранее а на лету, каждая следующая команда дает сервер, нагрузка на который в последние секунды была минимальной, в командной строке это все будет красиво выглядеть с использованием пайпов:

command_generator | parallel -j 100 >> parallel.log 2>> parallel.err

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

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

p.p.s. настоятельно рекомендую делать так чтобы воркеры в данной реализации самостоятельно обрабатывали ошибки, вплоть до вывода в stdout/stderr, иначе разбирать кашу вывода parallel будет сложно

Воспользуйся findstr (аналог grep из мира linux, ищет подстроку в тексте)

dir /s/b /A:D "Internet Explorer" | findstr /C:"\\Program Files\\"

правда это ищет \Program Files\ в пути, не обращая внимания сначала ли она или с конца, но там есть поддержка регулярных выражений, ковыряйся

Apple запрещает разработчикам не использовать их движок, т.е. любой браузер на apple это просто обертка над одним и тем же webkit. Поэтому какая тебе разница?

Вроде в прошлом году, бы под давлением антимонополистов, apple обещали это требование ослабить.

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

Главный конкурент openai - Claude2 от anthropic, у них контекст порядка 100к токенов (но хуже chatgpt4, точнее там есть где превосходит, типа питон или математика)

Все остальное создано на основе api openai, и если тебе нужен какой то функционал, лучше использовать api

Попробуй far commander или total commander, это файловые менеджеры, работают с файлами лучше чем Эксплорер.

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

Т.е. увеличивая контекста в 2 раза, увеличиваешь требование к памяти в 4 раза а энергии на обучение ещё в 2 раза больше, т.е.8 раз (там тоже чем больше тем хуже оптимизация)

Напоминаю что объем памяти это капитальные затраты, а на вычисления (энергию) - операционные

Raid Level : raid1

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

Гуглятся инструкции

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

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

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

В настройках панели задач (как минимум в старых версиях windows до 8 и большие шансы что и у 10) можно указать отображать ее сразу на всех мониторах (такая настройка точно есть у приложения classic shell, возвращающую привычную win7 панель задач)

Ярлыки можно перемещать между мониторами без ограничений

Незаметно - только на своей странице (мало того, даже iframe доступен только со своего домена).

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

Бессмысленно.

Времена, когда через 2-3 года можно приобрести процессор за те же деньги но со значительно большей производительностью - прошли (лет 5 назад), 'закон мура' перестал действовать, потому что производители подошли к физическому пределу технологии.

Так же производители старательно придерживаются стратегии запланированного устаревания (все чаще и теперь выбор mid/high-end линеек может не защитить от этого) это значит что то в твоем ноутбуке через 3-5 лет уже не будет хватать для задач нового времени и менять его все равно придется целиком.