mayton2019

Это правильная формальная защита от программного обеспечения новичков. Не все из них - обладают благими намерениями и в данном случае предупреждение - правильное. Превентивное. Это лучше чем антивирус. Об этом кстати еще говорил Евгений Касперский в одном из своих интервью. Он считает что будущее - за тотальной цифровой подписью и сертификацией любых бинарников.

Принципиально эта задача не имеет решения. Если юзер хоть как-то на экране видит видео - то считайте что он его уже качает. Вопрос технического и программного оснащения - это вопрос времени.

DRM не поможет если плеер уже транслирует драгоценное видео с релизом вашего сериала - то вы можете купить HDMI-recorder и спокойно писать цифровое видео прямо с выхода видеокарточки.

Вывод - контент будет украдет полюбому. Поэтому лучше не парьтесь ерундой. А если у вас что-то реально хорошее - продавайте его как Megogo продает сериалы за небольшую плату.

120 гигабайт - это размер еще не Биг-дата но уже близкий к выходу за рамки оперативной памяти. Если исходный материал побит на файлы (небольшого размера) то я-бы предложил решать эту задачу через map-reduce.

Если удасться это сделать то реализация написанная на Python может работать быстрее во много раз за счет параллелизма. Я не говорю что на С++ не надо делать. Я просто акцентирую внимание что задача имеет специфику распаралелливания. Грубо говоря задача тяготеет к big-data и шаблонам паралельного процессинга для которых язык не особо важен а важна имеено эта опция.

По алгоритму. Ну я +1 к Антону.

Любая библиотека с поддержкой arbitrary-precission подойдёт.

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

Посмотри в утилиты
- binwalk
- foremost
- photorec

Они - толерантны к файловой системе и они восстанавливают известные форматы файла по сигнатурам. И если твой нужный файл был JPG/png/avi или им подобные то есть вероятность что он будет спасён. Но эти утилиты - без гарантий и на твой страх и риск.

У меня было 3 флешки. И у всех трёх наблюдалось разное поведение при копировании. Скорость. Буфер. Зависание.

Согласен со всеми ораторами.

Топик совершенно не так должен звучать. Автор видел уязвимость. Что это было? Почему оно имело эффект в exim (? что такое exim?) и вдруг не будет имет эффекта в виртуальной среде.

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

Да кто вообще докер сертифицировал на безопасность? Тоже мне крепость.

Это было создано более 15 лет назад CreativeLabs. У них есть технология EAX. И к ней есть доступ через Microsoft Direct Sound 3D. Я играл еще в старые версии Half-Life и я помню этот пугающий трехмерный звук. После перехода от старой железки SoundBlaster 16 bit на Creative - разница конечно чудовищная. Молодым - не понять.

По поводу Питонов и прочих линуксов. С этим конечно тухляк - т.к целевая аудитория почти нулевая. Но погугли по ключевому слову OpenAL. Это по идее тоже должно иметь интерфейс доступа к железу EAX но насколько там хорошо и полно воплощены фичи - ХЗ.

Для хранения толстых файлов обычно покупают Amazon S3.

Город похож на город когда дома и кварталы в нем имеют углы - близкие к 90 градусов. Такой вот нечеткий криетрий.

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

1) Очень сильно удивлен тем что делает автор. Категорически нельзя бэкапить базы данных через реплики образов. Или на это время БД нужно останавливать. Есть риск что всё что накопировал автор - будет бесполезным хламом т.к. после восстановления БД не поднимется. Будет много corruped block. И неконсистетных данных.

Поэтому вопрос - автор ты вообще пробовал восстановить весь комплекс с такого неконсистентного бэкапа?

2) Если база 1С стоит на MySQL или на PG то надо использовать коробочные утилиты дампа my*, pg* dump.

В игровых технологиях сцена - компилируется. Это нужно чтоб в реалтайме расчет был как можно более быстрый. Это достигается за счет предположения что 80% объектов игрового мира - стационарны. Как камень и не двигаются. Именно за счет них достигается самая львиная часть ускорения. Это внедрили еще в 1990х при разработке Quake. Вся сцена компилируется в специальные структуры данных. +Игровые технологии ослабляют точность в угоду спец-эффектам. Часть визуальных эффектов - не настоящие а симулируются за счет 2D. Например зеркальный шар - не настоящий практически всегда. А отражает в себе ambient тоже заранее специально скомпилированный. Поскольку времени компилляции не жалко - сцену можно пре-процессить хоть неделю. Главной чтобы геймер был доволен.

Поскольку в CAD системах любой элемент модели - можно двигать то такой подход здесь не катит. Главная задача - инженерная. А инженеру - плевать на спецэффекты. Ему если хотите знать лет 20 назад достаточно было бумажного листа и 4х проекций.

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

А если твой ГСЧ - криптостойкий - то это считай дело безнадёжное. Он спецом создавался чтобы никто и никогда не догадался о прогнозах.

ГСЧ - это что-то дискретное. Здесь больше подходит комбинаторика и ГА. Например просто проверить принадлежность твоему датасету какому то классу величин. По повторам. По форме распределения. Если оно не линейное.

Теги можно хранить в поле типа JSONB