в erlang данные под капотом на самом деле не копируются без надобности (copy on write), даже если вы изменяете только часть данных — то только они и изменятся на остальные будут ссылки. Поэтому расход памяти не особо и большой получается.
Авторизация как хотите через токен, куки или еще что — вам решать
Механизмов много и на самом деле к каждому полю можно сделать `resolver` в котором можно решать и проблемы доступа и прочее, нет весь запрос не обломается
Лаунчер сливает файл при запуске (тут всякие варианты кеширования, но он все равно мелкий хоть на cdn клади)
Благодаря libtorrent просто запускаем на скачивание этот файл (он сам проверит хеши файлов и перекачает изменения, причем от размера блока и файла зависит сколько он скачает)
Дожидаемся 100% — профит, причем раздачу можно оставить на небольшой скорости.
// Сарказм
А Рами Малек у вас чтоли учился? А настоящее имя — Максим Ковалев? И он с этим согласен? Обучался на веб-разработчика а стал актером, процесс обучения видимо завернул не туда. Точно на веб-разработчика то учите?
ОСи не делаются из расчета ядер, им вообще побоку. Ось и на одно будет нормально работать, а вот остальное необходимо по больше части для софта. И тут уже зависимость от того как софт в многопоточном режиме умеет работать. Если не умеет — то важна скорость ядра и не их количество.
если бы посмотрели спеку то стало бы понятно что fill заполняет массив одним экземпляром, т.е. каждый элемент массива — это ссылка на один и тот же объект
Механизмов много и на самом деле к каждому полю можно сделать `resolver` в котором можно решать и проблемы доступа и прочее, нет весь запрос не обломается
Но несколько проще:
А Рами Малек у вас чтоли учился? А настоящее имя — Максим Ковалев? И он с этим согласен? Обучался на веб-разработчика а стал актером, процесс обучения видимо завернул не туда. Точно на веб-разработчика то учите?
Тут на самом деле смысл в закачке payload на консоль, которая находится в режиме восстановления.