Если уж впадать в маразм, то можно считать, что в мозгу есть длинный ключ для связи только с одной определенной душой, и утеря ключа в связи с информационной смертью мозга сделает невозможным восстановление подключения именно к той душе, что была. Ну или что при разрыве соединения с душой ее собирает garbage collector, т.к. к ней больше нет референсов. Тут уже целый спектр вариантов на усмотрение страждущего :)
Ну а что до аналогий — вы их просто не поняли. Я говорю о том, что когда мозг разложился в говно, то из говна собрать мозг уже нельзя. И как пример привожу хэш. Как другой пример — если у вас были числа 4, 8, 15, 16, 23 и 42, а потом вы взяли их и просуммировали, получив 108, то вы не сможете восстановить из числа 108 оригинальную последовательность, вне зависимости от того, насколько сильно разовьется математика или технология. Можно получить много разных вариантов того, что в сумме дает 108, но на самом деле это тождественно пониманию того, что самые разные мозги в конечном итоге превращаются в компост, независимо от того, кому они изначально принадлежали.
Ну, скажем так, моя категоричность обоснована, если только не принимать во внимание всякую антинаучную хрень типа «мозг это просто приемник сигнала от души». Как нельзя по короткому хэшу определить, от каких длинных данных он был взят, так нельзя из плесени и липового меда восстановить мозг усопшего. Это утверждение было справедливо миллионы лет назад, когда некому было заниматься математикой, и будет справедливо и после того, как во Вселенной не останется ничего, кроме излучения.
Во-первых, умерших вернуть невозможно, если мозг разрушился. Тут вопрос не в уровне технологий, а в принципиальной невозможности восстановления сознания на любом носителе после информационной смерти — если мозг уже превратился в компост, то из компоста ты мозг не соберешь.
Во-вторых, кому в принципе нужны умершие? Самим умершим это не нужно, они уже ничего не хотят. Себе, потешить воспоминания?
Да, и ко всему вышеуказанному — реализация автора статьи однопроходная. Ты указываешь имя файла, которое нужно извлечь, а оно ищет его и извлекает. Это хороший подход, когда весь архив уже в памяти, но если его нужно для каждого файла переизвлекать из gzip, то лучше переписать эту часть логики на "встретил файл — спросил коллбэк, что с ним делать".
Если бы речь шла о .tar-файле на диске — никаких проблем, mmap туда просится естественным образом. Но как натравить mmap на результат распаковки какого-нибудь gzip?
Хорошо, я понял вас, и я с вами согласен — но вы не уловили мой момент. Допустим, у нас в архиве хранятся текстуры. Эти текстуры ведь не представляют для нас интереса в виде блобов — с ними нужно что-то делать, верно? Загружать в тот же OpenGL, например. Ну или, скажем, не текстуры, а JSON-строки, которые нужно распарсить и превратить в дерево объектов. Итого, выходит, хронология использования памяти за время жизни приложения:
Пиковая загрузка, выходит, 2 GiB, рабочий режим — 1 GiB. Если бы библиотека позволяла итерироваться по файлу, то загрузка была бы следующей:
0MiB — запустились
+240 MiB — распаковали одну текстуру и скопировали в память (итого 240 MiB)
+200 MiB — загрузили текстуру 1/5 из памяти (итого 440 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 200 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 440 MiB)
+200 MiB — загрузили текстуру 2/5 из памяти (итого 640 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 400 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 640 MiB)
+200 MiB — загрузили текстуру 3/5 из памяти (итого 840 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 600 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 840 MiB)
+200 MiB — загрузили текстуру 4/5 из памяти (итого 1040 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 800 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 1040 MiB)
+200 MiB — загрузили текстуру 5/5 из памяти (итого 1240 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 1000 MiB)
Итого в таком случае мы бы тратили память только на хранение контекста распаковки и сырых данных.
С другой стороны — ресурсы же всё-равно будут использованы, т.е. будут загружаться. Тогда почему бы не загрузить их с диска сразу, а уже по надобности брать их из массива с tar-данными.
Вы один раз считываете сжатый файл, затем разжатый файл скармливаете своей функции, затем выхлоп фунции скармливаете тому, что должно обрабатывать конечный ресурс. Итого, если у вас задействован каждый файл, и каждый файл после загрузки находится в памяти, пиковое потребление оперативки превышает размер архива чуть больше, чем в два раза. Если бы индексироваться по самому файлу, не считывая его в память полностью, затраты памяти были бы меньше, т.к. хранилось бы только непосредственно прочитанное.
Крупная развлекательная компания привлекает автора инновационного ИИ к созданию мультиплеерной ММО игры. ИИ создает весь контент игры на ходу, подстраиваясь под игроков. Маркетологи поставили перед ИИ цель — сделать так, чтобы игрокам было интересно, согласно слогану компании-заказчика, и максимально охватить ЦА, по возможности расширив ее. ИИ, в ходе самосовершенствования в целях выполнить задачу в условиях ограниченных ресурсов, сначала кардинально улучшает собственную элементную базу, а затем разрабатывает технологию прямой загрузки сознания в вышеуказанную ММО. С точки зрения ИИ, это позволяет игрокам лучше проникнуться ценностями компании-заказчика. Для того, чтобы покрыть как можно большую аудиторию, ИИ прибегает к шантажу, физическому устранению, подлогу, взлому, уничтожению информации, намеренной дезинформации, политическим интригам и т.д. В конечном итоге ИИ перевыполняет ожидания маркетологов и загруженными оказываются не только фанаты бренда и безнадежно больные, но и люди, поставленные ИИ в безвыходное положение с сохранением видимости формальной добровольности. Любые попытки сопротивления пресекаются на этапе планирования путем полупринудительной загрузки возможных лидеров сопротивления. В конечном итоге железным кулаком в мультипликационное счастье вколачивается все без исключения население Земли. ИИ переделывает в конденсат Бозе-Эйнштейна сначала вещество всей планеты, затем всей солнечной системы, затем тянет щупальца в другие звездные системы, расширяя симуляционную сеть. В виртуальном пространстве тем временем беззаботно живут бывшие люди, у которых больше нет никаких забот, кроме стагнации.
Интересно, а вот такие разработчики малвари — у них тоже есть билд-сервера и CI/CD? Багтрекеры на какой-нибудь JIRA, карточки в Trello, чаты в Slack, да и команда в духе SCRUM, с product owner-ом и user stories… :)
«Как инфицированный пользователь, я хочу включить компьютер и увидеть сообщение с требованием выкупа, чтобы заплатить выкуп и получить обратно свои файлы»
А потом произойдет вот это https://habrahabr.ru/post/202460/
Главное — это нескучные темы оформления. А то надоела эта скучная стандартная Darcula — кодишь, кодишь, все одно и то же… Неинтересно.
Не убрали — https://github.com/kak-tus/PiterJump/commit/3d64c35aaa56f3f286b91c0441d8dae9f847f577
Ну а что до аналогий — вы их просто не поняли. Я говорю о том, что когда мозг разложился в говно, то из говна собрать мозг уже нельзя. И как пример привожу хэш. Как другой пример — если у вас были числа 4, 8, 15, 16, 23 и 42, а потом вы взяли их и просуммировали, получив 108, то вы не сможете восстановить из числа 108 оригинальную последовательность, вне зависимости от того, насколько сильно разовьется математика или технология. Можно получить много разных вариантов того, что в сумме дает 108, но на самом деле это тождественно пониманию того, что самые разные мозги в конечном итоге превращаются в компост, независимо от того, кому они изначально принадлежали.
Во-вторых, кому в принципе нужны умершие? Самим умершим это не нужно, они уже ничего не хотят. Себе, потешить воспоминания?
Ну так никто и не предлагает дергать внешнюю компанию — под "gzip" имеется в виду формат архива, а не исполняемый файл, оный архив извлекающий.
Да, и ко всему вышеуказанному — реализация автора статьи однопроходная. Ты указываешь имя файла, которое нужно извлечь, а оно ищет его и извлекает. Это хороший подход, когда весь архив уже в памяти, но если его нужно для каждого файла переизвлекать из gzip, то лучше переписать эту часть логики на "встретил файл — спросил коллбэк, что с ним делать".
Если бы речь шла о .tar-файле на диске — никаких проблем, mmap туда просится естественным образом. Но как натравить mmap на результат распаковки какого-нибудь gzip?
А почему для
[+]и[-]были выбраны триграфы, а не пара вида{и}?0MiB — запустились
+40 MiB — прочитали сжатый файл (итого 40 MiB)
+1000 MiB — распаковали сжатый файл в память (итого 1040 MiB)
-40 MiB — выгрузили сжатый файл (итого 1000 MiB)
+200 MiB — загрузили текстуру 1/5 из файла (итого 1200 MiB)
+200 MiB — загрузили текстуру 2/5 из файла (итого 1400 MiB)
+200 MiB — загрузили текстуру 3/5 из файла (итого 1600 MiB)
+200 MiB — загрузили текстуру 4/5 из файла (итого 1800 MiB)
+200 MiB — загрузили текстуру 5/5 из файла (итого 2000 MiB)
-1000 MiB — выгрузили распакованный архив (итого 1000 MiB)
Пиковая загрузка, выходит, 2 GiB, рабочий режим — 1 GiB. Если бы библиотека позволяла итерироваться по файлу, то загрузка была бы следующей:
0MiB — запустились
+240 MiB — распаковали одну текстуру и скопировали в память (итого 240 MiB)
+200 MiB — загрузили текстуру 1/5 из памяти (итого 440 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 200 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 440 MiB)
+200 MiB — загрузили текстуру 2/5 из памяти (итого 640 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 400 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 640 MiB)
+200 MiB — загрузили текстуру 3/5 из памяти (итого 840 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 600 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 840 MiB)
+200 MiB — загрузили текстуру 4/5 из памяти (итого 1040 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 800 MiB)
+240 MiB — распаковали одну текстуру и скопировали в память (итого 1040 MiB)
+200 MiB — загрузили текстуру 5/5 из памяти (итого 1240 MiB)
-240 MiB — освободили память из-под текстуры и контекста распаковки (итого 1000 MiB)
Итого в таком случае мы бы тратили память только на хранение контекста распаковки и сырых данных.
«Как инфицированный пользователь, я хочу включить компьютер и увидеть сообщение с требованием выкупа, чтобы заплатить выкуп и получить обратно свои файлы»