mayton2019

Нужно понять от кого автор защищается. От лоха - да это прокатит.

1) Если диск будут смотреть специалисты - они увидят подозрительную разность в физическом объёме диске и доступное место на фейковом диске.

2) Я пока себе не представляю алгоритм. Симметричная криптография нигде не хранит ключ. Поэтому реализовать этот выбор фейковая-нефейковая мне пока не представляется никак возможным. Просто в случае кривого пароля у вас не поднимется никакая ОС.

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

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

Обычная дисковая подсистема на домашнем ноутбуке состоит из 1 HDD/SDD. И он не параллелится. Тоесть это такое жлобское устройство которое в 1 момент времени может обслуживать чтение и запись 1 блока файловой системы (или сектора или кластера неважно). Поэтому параллелизм толком ничего не дает. Однако если у вас какие-то RAID массивы или сеть хранения данных то она может обеспечить такие действия.

Что еще в задаче плохо.

while(!InputFile.eof())
    {
      getline(InputFile, tmpString);
    }

Непонятно что здесь происходит? Перемотка в конец файла? Почему так дорого? Почему мы должны каждый раз получать строки? Ведь нам нужна только последняя? Может надо было взять первую? Вобщем непонятно.

Вот если-бы автор решал задачи наподобие map-reduce где работают с большими файлами тогда параллелизм был бы понятен. Там чтение блока файла чередуется в вычислениями.

Здесь вычисления - мелкие. И большая часть процессорного времени зря сгорит в старт-стопах потоков и в финальном join потоков (которые я кстати не вижу).

Тут наверное OpenCV не надо. Просто замерять цвета нескольких точек в течение 3-5 секунд (как фотик наводит резкость) и брать их среднее значение.

Этот алгоритм прост - как автомат Калашникова. А все что простое - работает быстро. Как будет работать OpenCV на Raspberri мне даже страшно представить. Скорее всего плохо т.к. OpenCV проектировалась сразу для сильного железа а Распберри это больше игрушка для энтузиастов чем платформа для видое-обработки.

Это Груви? Как это вообще скомпилировалось? Справа что стоит? Символ или строка?

value = value.replace(' ','');

Я вот не пойму. Автор что на 5 языках пишет? Полиглот прям.

По теме. Лет 20 назад у линукса был ужасный UI. И установка драйверов видяшек - это челендж еще тот был.
Сегодня он достаточно прилизан. И шрифты хорошие есть.

Да. Докер неудобно использовать на Windows.

Да. Имеет смысл в наше время практиковаться в командной строке Linux/Unix/BSD чтоб иметь в крайнем случае заработок девопса если будет создан ИИ и всех программистов уволят. Или если ты будешь стар и глуп и негоден к современной скрам аджайл разработке. Или если твоей бабушке надо будет настроить файрвол или почту. Или просто если будешь перед друзьями "понты колотить". Например mp3 плеер запустить из консоли. Или хакнуть сайт своей школы. Вобщем много плюшек. Думай.

Можно написать веб-приложение на Питоне и запустить его на Raspberri.

Неудивительно что ты ничего не нашел. Работа с Xml - это на 90% работа с кастомными библиотеками.

Вот посмотри обзорная статья
https://www.baeldung.com/java-xml

С файловым сервером - задача лишена смысла. Можно вообще не удалять.

А задача автора - звучит как "кольцевой буфер". Пишем данные по кругу. Можно гранулами. Мелкими файлами.
Новые переписываем поверх старых.

Как сделать это в Android - я не знаю. Т.к. я больше специалист по серверной Java.

Все что написал автор не имеет особого значения. Языки выбирают вообще не по такому принципу.
Любой из них - вашу задачу решает. И на 99% выбор будет обусловлен экспертизой вашей команды
по отношению к ЯП.

И оцените риски принципиальной невозможности что-то сделать. Например - запустить фоновое задание или поток внутри процесса Node. Это - важный момент и Liberrum Veto, который может просто исключить какой-то
язык или технологию из списка вообще.

Эта задача похожа на поиск в глубину DFS и на задачу об укладке рюказака.

Как решить ее на Хаскеле - я пока не знаю. Надо думать. Особенно в части поиска
оптимальности и вообще доказательства того что решение существует.

Доказательство - важно если вы представите что цены на коров - иррациональные числа на пример.

Почитайте про Web-assembly. По идее эта технология позволяет просто запускать очень быстрый код в среде браузера. Насчет языков я не скажу.

Ты не указал внутренний IP куда будут ходить пакеты на 113 порт.

Автор описал типичный ETL-процесс. (Extract-Transform-Load). Такие процессы
1) Не пишут на PHP
2) Используют спец-утилиты импорта (названия разные и зависят от DBMS)
3) Сама DBMS и таблица подготавливается к этому.
- отключаются триггеры и констрейнты
- дропаются индексы.
- используются режимы транзакций максмиально ненагружающие I/O. Тоесть никакого мать ево авто-коммита быть не должно.

В конце триггеры и индексы возвращаются в исходны статус.

Скорость подобного ETL на 80% зависит от этих пунктов что я описал.

И еще раз повторю. На PHP это не делают.

Правильно сказано про миллион.

Но смущает 1) Хеш тег Node.JS. Этот фреймворк архитектурно был однопроцессным. Возможно тут автор решает задачу которая решается на самом деле по другому. 2) Непонятна "выделенная среда". Что это? Еще один процесс в текущей ОС? Еще процесс в контейнерах LXC/Docker? Процесс в виртуалке? Процесс в другой EC2 ?

Подумай о том что переименование - это тоже неоднозначная операция. К примеру у тебя был фолдер

/svn
/.svn

и после переименования у тебя файлы из точка-свн сливаются с свн со всеми последствиями. С переписыванием
и потерей нужных файлов.

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

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

Против алгоритмов Брезенхема не имею ничего против. Но это про другое.

Несколько мыслей.
1) Бот должен идентифицироваться как браузер. Тоесть генерировать все хедеры как ваш Opera/FireFox/Edge.
2) Бот должен отрабатывать все входящие JavaScript на страничке.
3) Бот должен кликать "задумчиво". Тоесть иммитировать поведение обычного чела. С паузами.

Насчет литературы - вряд-ли. Слишком специфично. Но тут КМК нужны разумные пределы когда стоит остановиться. И может быть такой бот действительно будет стоить дороже чем 1000 китайцев в час.