Это одна из фундаментальных проблем криптографии и криптоанализа.
Чтобы подделать нужно знать алгоритм и ключ. Алгоритмы обычно известны.
AES, Blowfish e.t.c. Их можно перебрать. С вариациями длины ключа там будет
несколько сотен. С ключом сложнее. Современная инфо-безопасность требует
ключи до 256 бит. Поэтому их даже в цикле перебрать невозможно. Получается
астрономически большое число итераций.
Несколько мыслей. Насколько я помню zip-формат ничего не знает о многотомных архивах. И видео-файлы обычно не архивируются. Тоесть пользы от упаковки их в архив обычно никакой.
Не советую читать Кнута. Вы просто зря потеряете время. Если нужно быстро понять базовые алгоритмы сортировки и поиска - то лучше Никлаус Вирт или Седжвик. Кнут слишком нуден и растягивает на 4 тома то что можно выложить в брошюре. Говорю с позиции практика так как мне Кнут и его выдумки не пригодились. Говорю выдумки потому что Кнут все четыре тома вас будет грузить исходниками на виртуальном процессоре MMIX которого не существует в природе. А зачем вам это душное душнилово?
Вот Седжвик есть в вариациях на Java/C++/C. Берите его. У Вирта - Паскаль что тоже вобщем хорошо для изучения.
Вообще сомнительно что это хоть где-то кроме Google Colab можно поднимать.
Тут и более простые задачи lambdas требуют кардинального переписывания при переходе с AWS на GCP.
А вы говорите - модель.
Тут скорее всего не формат важен а стратегия в целом. Как бэкапируется и где хранится.
Например для Моих Документов может быть один подход (архивом bzip2) а для фолдера
с фильмами по другому (rzync). Это обеспечит и скорость и управляемость хозяйством.
Полностью поддерживаю Сергея с правилом 3-2-1.
Если у вас будут ошибки или физические повреждения носителя то вам не особо поможет Fat/ExFat.
Главным вопросом будет - "где вторая копия" ? А кустарные методы восстановления - мы опустим.
Слишком это всё спорно и без гарантий.
очень резко сужает наши возможности. И мы никак не сможем это требование
обеспечить если будем вульгарно прыгать с одного компиллятора на другой (MinGW)
или спорить о С++ или C.
Я думаю Александр полностью ответил на вопрос. Стандартное средство - wget. И оно работает для 80% сайтов. Должно работать.
Другое дело что современные сайты из всех сил сопротивляются скачиванию. И поэтому для них
очень трудно искать какой-то стандартный подход. Задача еще осложняется анти-капчей и прочими
вопросами которые просто wget не решает.
Если например смотреть в сторону Селениума и прочих браузеров которые эмулируют полноценную интеракцию - то даже они требуют ручной доводки и конфигурирования. И это уж точно никак не пользователский подход. Это скорее какая-то разработка.
Вобщем я кликаю что решение вопроса есть. И можно дальше ничего и не искать.
zilevsky, некоторые небольшие кусочки бинарных данных (токены, ключи, сертификаты) хранят в базе в виде строк в кодировке Base64 или BinHex. Это удобно. Они обычно не больше 4к. И есть удобство кидать их через клипборд во время разработки и тестирования.
Но если данные большие и будет нагрузка (много пользователей захотят читать много документов) - то надо хранить в дисковых хранилищах. А в базе просто класть Url на файлик который лежит где-то там.
Вообще база с точки зрения суммарной стоимости владения - всегда дороже чем дисковое хранилище. Базу надо беречь и не пихать в нее нереляционные данные. Исторически базы были созданы для хранения коротких строчек и чисел. И если в них класть блобы - то таблица всегда деградирует по производительности. И бэкапы становятся безумно долгие и малополезные.
Не напасёшся правил. А если он потом захочет более сложную проверки на больше-меньше?
Проще арифметику проверять там где появляется арифметический контекст.
Double.parseDouble(operand)
если результат этого > 10.0 и т.д. - то бросать RuntimeException.
А автор большой лентяй и очевидно что чужую лабу сдает. Позор!
Не знаток оптимизаций в mysql, но если у нас работает inner join с 5 таблицами то нам надо форсировать такой план соединения при котором самое селективное соединение выполнится в первую очередь. Как управлять порядком соединения в mysql - я не знаю. Есть ли там хинты? Можно ли скобочками или inline views создать видимость порядка.
Как ускорить тут order-by - непонятно. Вообще сомнительно что его можно оптимизировать. Проще пересмотреть ТЗ и решить что этого не надо делать.
