mayton2019

ntfs - не родная система для этого дела. Если вы так по чесному хотите смигрировать на Ubuntu - то уходите совсем. Если хотите держать две ОС - то может лучше загружайтесь с флешки. Если вам ценна та инфа которая осталась на ntfs разделах.

Можно начать с построения семантической сети по тексту.
После того как сеть будет построена. Задача бота сводится по поиску вершин и рёбер в этой сети.
Вершины и ребра будут по сути ответом на поставленный вопрос.

С ботами я никогда не имел дела. Но разбирался как работает RDF/Semantic web/GraphQl.

Но это всё из области четкой логики. Из того что умерло в 80х вместе с языком Пролог и Лисп.

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

Хотя КМК НС плохо подходят для текстовых задач. У них есть большой лимит по памяти. Сеть хорошо
обобщает факты. Но плохо помнит частные случаи.

Что такое 123 и 555 ? Это переменные? Или константы?

Это важно понимать для дальнейшей оптимизации.

Совершенно нет никакой мотивации к использованию uuid.

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

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

В старом Апаче это называлось - виртуальный хостинг. Один Ip - и много имён в dns.

Это очень опасный пример. Он завязан на фазы уборки мусора. Прогрев JIT. И размер кешей. В зависимости он версий java и ос. И никакой синьор-помидор тут не сможет точно сказать какие переходные процессы текут во 2 варианте кода.

Как переписать - я не знаю. Но мультипоточка всегда полезна при парсинге множества сайтов одновременно. Вот пускай автор сделает веб краулер.

Если белая это 0. Штрихованная это 0,5. Сплошная -1. Тогда на каждой итерации добавляем по 0,5 крестиком. Для каждой небелой. На 4й день все поле будет в единичках.

Мне видится такая декомпозиция.
1) перевод источника (mp3/aac/ogg) в формат pcm.
2) распознавание ритма и основной мелодии и гармонии. Выделение отдельных инструментов и классификация.
3) рендеринг ударной партии и сведение сольных партий с дистошеном.
4) pcm -> mp3

Пункт 2 является самым сложным. За него даже заплатят денег если автор осилит это.

Остальные пункты этого задания технически решены и интереса не представляют. Они - утилитарны.

Схема при которой пользователь вводит НЕЧТО с клавиатуры и это нечто расматривается как ключ шифрования - очень слабая схема и не выдерживает атак. Пользоватль ленив и глуп. И всегда будет стараться вводить пароли и ключи по 1-2 символа. С этим ничего не поделать. Поэтому если автор заинтересован чтобы поле ключей было более сложным - надо использовать во первых SALT в совокупности с паролем. И использовать функцию хеширования наподобие SHA1 чтобы получить более-менее сложый ключ. В некоторых случаях (сеансовые ключи) можно получить энтропию из внешнего мира (часы в микросекундах и текущее положение мышки на экрасне).

Тоесть само наличие в схеме алгоритма RC5 еще не гарантирует что у тебя система надежна. Нужно чтобы ее использование было чистым и лишенным человеческого фактора.

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

В топике КМК спутаны несколько вопросов. Сжатие и кроп - это разные методы. И crop теоретически
повреждает картинку убирая из нее потенциально значимую часть сведений (копирайты или
надписи внизу). Поэтому надо обговорить твоё задание не с бухты-барахты а более детально.

Что делает imagecompressor - я не знаю. Но предположительно он берет JPEG и прогоняет по нему WEBP
алгоритмы и потом перегоняет обратно в JPEG используя некую совместимость между ними. В цифру
70 % я не поверю. Там скорее всего идет какой-то нечеткий критерий. А в условиях нечеткости можно написать
любые проценты и при этом окружающие покивают головами ведь критерий-то нечеткий.

По поводу сервиса. Я-бы поднял AWS-Lambda и поставил туда какой-то опенсорцный JPEG-WEBP кодек
и использовал бы для себя как конвертер. Но по последнему пункту тебе надо искать программиста
под AWS.

Они так и называются SHA1 - Secure Hash Algorithm 1, MD5 - Message Digest 5.

Тебе по сути надо 300 файлов разложить на 2 кучки. SQL и не-SQL верно?

Автор у тебя уже есть какой-то HelloWorld для 8086 где есть каркас этого приложения?

Опубликуй пожалуйста. Я думаю что это будет очень продуктивно иначе участники топика не поймут что именно тебе непонятно.

Непонятно что такое "хост" и как с него можно что-то собирать. Хост - это технический термин. Не бизнесовый и наверное в топике имелось в виду другое. Может на этих хостах - ftp/cifs файловые хранилища?

Правильно выше пишут. Технически tar+cron решает эту задачу. И обычно самое простое решение - самое надежное. Если "хочется отслеживать" - то это уже другая задача. И она не имеет прямого отношения к бэкапу. Тоесть вопрос состоит из двух независимых частей. Собственно бэкап. И какой-то мониторинг который должен ... что то мониторить.