24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Блять, объясните, как такое может быть сжимаю winrar-ом 10 гигов, в zip, время сжатия 6 мин, на выходе архив весит 10 мб сжимаю в rar, время 1 минута, на выходе 4 мб
>>161722276 Судя по разнице размеров в тысячу раз, у тебя этот архив пустой по сути, меньше бита информации на тысячу бит ёмкости. А это крайний случай, алгоритмы сжатия на это не настроены и никто не анализирует и не сравнивает их работу в таком режиме. >>161723648 Сделай десять гигабайт нулей, и он у тебя успешно сожмётся до килобайта.
>>161723648 >>161723533 Может он текст сжимает, тогда это вполне реально. Текстуры модов татуировок для скайрима скачиваются в 40Мб, а при распаковке дают 5Гб, например.
>>161723533 Теоретически возможно, если, например, ОП-пиздабол сжимает 10 гигабайт текста "аааааааааааааааааааааааааааааааааааааааааааааааааааааааа..." ну ты понял. В искусственных условиях такое возможно. А так, я воспринимаю это как приглашение к холивару rar vs zip. Zip, конечно, лучше. В 2017 году только необучаемые дауны на винде пользуются winrar-ом, и обмениваются rar-архивами с таким же даунами.
>>161724880 Самый минимальный размер можно получить только универсальным архиватором rm (нулевой размер) Зависит от того, какие файлы ты собираешься сжимать и как быстро тебе их нужно распаковать потом
zip.exe самые пиздатые архивы Скачиваешь zalupa_kentavra.zip.exe в 2 мегабайта, а при распаковке она занимает ~2 гига на жестком, 4 гигабайта оперативки и 99% процессорного времени. Делайте выводы.
>>161725179 7zip сильнее на несколько процентов, чем WinRar, но сильно медленнее. По соотношению скорости к размеру WinRar оптимален. tar и прочее - полное говно. Ноунейм-алгоритмы могут сжимать сильно лучше или сильно хуже, в зависимости от конкретных данных, но все существенно медленнее WinRar.
>>161724710 Хуита. В цикле когда закрываешь и снова открываешь файл (нахуй кстати ты это делаешь) забыл аргумент "w" указать, не будет это говно работать как надо. Мудень блять.
>>161725851 Тащемта в питонах по дефолту там стоит "r" вроде как диванный, не помню. Может он хотел чтобы пекарня ОПа ахуела от выгрузки в оперативу 10 гигов.
>>161726102 >Тащемта в питонах по дефолту там стоит "r" Вот именно. На втором шаге цикла трейсбек вылетит, и не будет никаких 10 гигов. Там же запись в файл производится, "w" нужно указывать обязательно.
>>161726418 Так. Падажжи. Кажется дошло. В файл ничего писаться не будет пока файл не "закроется". Все дерьмо будет висеть в оперативке, так чтоли? Блин, ну трейсбек же будет. Чет интересно стало попробовать.
>>161726481 А мне кажется, что в файл запишется сразу по вызову метода. Ну ты это, попробуй записать строку в файл, а после бесконечный цикл чего-нибудь и чекни, добавилось ли что-нибудь в текстовый документ.
>>161726684 Проверял. В файл пишется только после закрытия файла. Похоже, поэтому говнокодер на каждом шаге цикла открывает и закрыавыт файл. Так то все правильно, кроме проебанного "w"
>>161725294 Ну вот смотри, у тебя есть текст из миллиона символов "а", файл .txt с этим текстом из миллиона букв "а", идущих подряд, весит, предположим, 8 гигабайт. Рационально будет сжать это всё в одну буковку "а" и указать, что при распаковке нужно будет этот символ помножить на миллион раз. Получаем мизерный архив меньше килобайта, который при распаковке даёт 8 гигабайтный файл. Это, конечно же, все я утрирую, и делается немного сложнее, но суть та же. На основе этого делаются зип-бомбы, которые весят несколько килобайт, а при распаковке получаются сотни терабайт, из-за чего пека наглухо зависает.
>>161726856 Примитивная задача - всего навсего закатать говна на 10 гб в текстовый файл оказалась полной подводных камней. Проще 10 гб путем Ctrl+C Ctrl+V делать.
>>161727052 Да хуле сложного блять? 5 гигов оперативы я думаю у человека найдется. Просто пилишь 2 файла по 5 гигов и объединяешь их. хотя да, похоже я обосрался и даже тут будут подводные камни
>>161727052 >Примитивная задача - всего навсего закатать говна на 10 гб в текстовый файл оказалась полной подводных камней. Разработка ядра linux. Начало.
>>161727158 >Просто пилишь 2 файла по 5 гигов и объединяешь их. Задача была только в том, чтобы просто запилить один файл на 10 гигов, а ты предлагаешь ее усложнить.
>>161727398 Окей. Проблема записать разом 10 гигов в том, что не у всех есть 16 гигов оперативы. А значит можно просто разом записать 5 гигов, скопировать файл и объединить их. Эти бляцкие 5 гигов записываются методом того же говнокодера, только НЕ НУЖНО лишний раз открывать и закрывать файл. Мы все это делаем лишь раз.
>>161727709 >Проблема записать разом 10 гигов в том, что не у всех есть 16 гигов оперативы. >А значит можно просто разом записать 5 гигов >НЕ НУЖНО лишний раз открывать и закрывать файл. >5 гигов. Зато НЕ НУЖНО лишний раз открывать и закрывать.
>>161727778 >Ну блять, знаешь, я не представляю как люди живут без 8 гигов А я не представляю для чего может потребоваться 8 гигабайт одновременно (кроме ебанутых скриптов, конечно). Если я запущу сразу все говно которое когда либо использую около 4-х гигов займет, да и то меньше.
>>161727964 >почему? Алгоритм тупанул над чем-то. Ты учитывай, что массово используемые алгоритмы сжатия заточены на универсальность. В каких то узких случаях они могут быть очень неэффективны.
>>161727964 > вся-суть-компрессии.жпг Когда ты сжимаешь файл, то на выходе можешь получить архив с бОльшим размером, вот так поворот. А тут ты сжимаешь уже сжатое, т.е. получить бОльший размер значительно увеличивается. А вообще вроде как рар в раре не изменяет размера.
>>161727907 Да-да, это я. >>161728029 Для игорей с комфортом. Для работы с адобами, буфером 4к изображений, И ЧТОБЫ ВАЛПЕПЕР ЭНЖИН РАБОТАЛ НА МАКСИМАЛКОХ.
>>161727964 А ты думал, что если сжать архив на 3,97 мб то он будет 3,96 мб, потом 3,95 мб и так пока до 0, 00...0001 мб не дойдет и таким образом можно будет бесконечное количество террабайт уместить в микроскопические 0,00000...00001 мб, да?
>>161728622 Плюс возможно алгоритм сжатия делает какую-нибудь "случайную" выборку. Попробуй ещё раз то же самое сделать. Если получится один в один тот же объем - значит разные стандарты.
>>161728873 брешь пустую банку. сгибаешь её. занимает меньше. разгибаешь и выпрямляешь - занимает столько же... ну эт босяцкий пример. или тебе с тех деталями нужно?
>>161729188 Простой вариант архиватора, есть 40 символов: aaaaasssssdddddfffff Сжимаем первый раз: 5a5s5d5f сжатие 60%. Сжимаем еще раз(опять спецсимвол, понятный нашему архиватору): ^4*5asdf Сжатие 50%
Под впечатлением от истории анона выше про zip-бомбы я кинулся было писать скрипт который будет генерировать огромный файл с нулями. Но тут возникает такой вопрос. Перед тем как его заархивировать его нужно где-то хранить. Так что сделать терабайтный файл с нулями на своей пеке уже не получится. Следовательно, мне нужно вникать в структуру zip-архивов и пытаться сделать сразу небольшой архив, который, будучи скормленный архиватору будет разворачиваться в неебически большой файл. Второй вопрос - а что с того, собственно. Вот юзер начинает его распаковывать, ОС немного поглючит и выдаст ошибку о переполнении оперативки/места в логическом разделе. Нельзя же записать файл больше, чем выделено под раздел. Никаких фризов наглухо не будет. Или нет?
Простой вариант архиватора, есть 25 символов: aaaaasssssdddddfffffggggg Сжимаем первый раз: 5a5s5d5f5g сжатие 40%. Сжимаем еще раз(опять спецсимвол, понятный нашему архиватору): ^55asdfg Сжатие 90% *
>>161729514 Смотря где он распаковывается, если это просто пека то космического эффекта не будет, а если это например роутер, который жрет обновление прошивки в формате зип, и ты ему подсовываешь зип бомбу, или андроид, которому ты опять же по ОТА притворяешься сервером обнов и пихаешь ему зип бомбу вместо прошивки, короче вариантов много.
>>161729587 >Почему? Имелся в виду не конкретный объем файла, а очень большой объем файла. Так понятнее? У тебя может и есть винт на терабайт или больше.
>>161726613 import os nb = 1 while True: with open("fucking_big_file.txt", "w") as fp: fp.write("a" * nb) if os.path.getsize("fucking_big_file.txt") < 10737418240: nb += 1 else: break Пофиксил вас обоих.
>>161729514 суть не в размере конечных файлов, а в том, что на оперативу будет нагрузка в несколько петабайт у зип бомбы например конечные файлы суммарно весят всего 64 гб
>>161729857 >суть не в размере конечных файлов, а в том, что на оперативу будет нагрузка в несколько петабайт А почему она будет? Есть же своп и времнные файлы. Любой архиватор их использует. Не будет такой нагрузки на оперативу.
>>161730018 Как что-то может занимать в оперативе петабайт, если самой оперативы скажем 8 гб? Да, такой пнг при попытке его открыть завесит просмотрщик и забьет всю свободную оперативу, но и только.
>>161730018 >https://xakep.ru/2015/09/03/png-bomb С png интереснее. По идее, пикчи целиком в память выгружаются. Но все равно же, будет просто сообщение ОС о переполнении оперативки и фриз приложения, которое держит пикчу. Но за ссылку все равно спасибо.
>>161730330 Зачем винде наебываться? У ядра для критичных вещей есть пулы (заранее выделенная память), поэтому ядру строго похуй. Наебнуться могут только кривые приложения, которые не обрабатывают ошибки аллокации памяти.
>>161729798 Бесконечный цикл, так как условие if os.path.getsize("fucking_big_file.txt") < 10737418240 никогда не выполнится. В файл ничего не пишется во время отработки цикла.
>>161730374 >>161730429 Нахуй иди, вот только что проверил, произошло именно так как я и сказал, фриз процесса, который я снял через таск менеджер, всё.
>>161730374 Архиватор не хранит ВСЕ данные в памяти при распаковке. Он хранит контекст, словарь, буфер, окно - называй как хочешь, зависит от алгоритма. А архиватор будет декодировать со словарем блок за блоком, декодированные блоки ему в хуй не вперлись, поэтому он будет писать их в целевой файл, вот и все. Количество занимаемой памяти при этом будет примерно одинаково на протяжении всего процесса.
>>161730445 Выполнится. Открываем файл, пишем байтики, закрываем, проверяем размер. Если мало, пишем на один байтик больше, закрываем, проверяем размер, и т. д. Ну ты пони.
>>161730156 Хм, я думаю, что на это стоит смотреть как на возможность залить на двач картинку размером ~100 гб, чтобы петарды охуели, зайдя в тред, фризанув браузер и слив моментально весь лимит трафака.
>>161730515 А разве with сам открывает/закрывает файл каждый раз? Если файл не закрывать/не использовать метод который пишет в файл, то os.path.getsize() будет смотреть на пустой файл каждый раз, а все дерьмо будет копиться в оперативке/временных файлах питона. Или нет?
>>161730701 Так це ж на размер файла, а пнг-бомба весит нихуя. Вот только перед загрузкой пикча все равно открывается чтобы показать тебе превью, так что ты только себя этой бомбой бомбанешь.
>>161730701 Ты тупой? Причем тут ограничение? Картинка может занимать меньше мегабайта. Раздувать ее будет отображающее ее приложение. Хотя, тогда получается это я тупой, так как только браузер фризанется, а слива трафика не будет. Годный тред, кстати. Люблю тебя, ночной.
>>161730938 Господа, это технологический прорыв. У нас вновь появилось оружие, с тех пор как вайпалки стали бесполезными из-за капчи. И это оружие совершенно.
>>161731121 Доставьте вебмку про школьника который играет в майнкрафт и потом кричит "бляяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя", а потом его мамка орет "я тебе щас дам блять, блять".
>>161731304 А такое изображение получится сделать? Тут как-бы суть в том, что именно охуенно большая пикча (много пикселей) сжата по стандартам png, а когда приложение пытается ее отрендерить оно фризится. 1 пиксель не имеет смысла. Или имеет?
>>161731304 Не получится. Декодер посчитает, сколько ему нужно (ширина x высота x байтовнацвет) и не будет распаковывать из сжатого потока больше, чем необходимо.
>>161731536 Так ты прикинь какой он будет когда разархивируется! Блядь, ну ман дд сделай и посмотри какой командой размер ограничивается, че ты как блондинка.
>>161731876 Очнись, ты серешь. Торрент без DHT это и есть файлообменная сеть, но анально завязанная на трекер(ы) прописанные в файле. Торрент с DHT это почти полный аналог какого-нибудь е-осла. Во многих клиентах даже есть поисковик, позволяющий искать файлы без участия трекеров или агрегаторов по нескольким трекерам.
>>161731941 > Торрент с DHT это почти полный аналог какого-нибудь е-осла Разговор был про хэши. В осле хэши идентифицируют файл, в торрентах - метаданные. Два разных торрента с одинаковыми файлами могут отличаться, потому что отличаются метаданные (банально порядок файлов).
>>161721489 (OP) Сколько раз не пытался ради эксперимента сжимать разные файлы разными методами 7-zip'ом, всегда хуета получалась, не больше 1 мегабайта сжималось в лучших случаях.
>>161731682 Проверил. Во-первых, cat /dev/zero | gzip не получится. Надо: cat /dev/zero | gzip -ck > puk.zip ... Ctrl+C Во-вторых: unzip puk.zip Archive: puk.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of puk.zip or puk.zip.zip, and cannot find puk.zip.ZIP, period.
>>161732121 Питон есть на все основные платформы, в том числе и на винду. Его недолго скачать и установить. А вот утилиты GNU на винду не поставишь. Вернее, можно поставить какой-нибудь имитатор линукс, но это несколько сложнее чем скачать экзешник с инсталятором с python.org и нажимать "Ок", "Далее".
>>161732326 > А вот утилиты GNU на винду не поставишь. Лож пиздежь. Есть MSYS, есть гораздо более охуенный MSYS2 с пакетным менеджером от арча. Прописываешь все это счастье в path, и у тебя винда с гнутыми командами. Можно даже баш юзать, если не смущает трансляция путей в single-root.
>>161732436 Читать умеешь? Читай: Lates Python <номер версии> Release Последний релиз Питон <номер версии> Вот это и качай. Код выше для третьей версии.
>>161732447 Python 3.7.0a1 - 2017-09-19 Download Windows x86 web-based installer Download Windows x86 executable installer Download Windows x86 embeddable zip file Download Windows x86-64 web-based installer Download Windows x86-64 executable installer Download Windows x86-64 embeddable zip file Download Windows help file Который?
>>161731854 Опяттаки, могли быть форматы привязанные к разрешению конкретной машины с фиксированным разрешением - цга и пиздос, например. И вытекшие в мир пек.
>>161732551 Ну может и есть. Я, кстати, еще про RGB вспомнил и прочие SGI-шные форматы. В простейшем случае это файлы без заголовка, содержащие квадратные картинки с шириной, равной степени двойки. Какой именно степени - абсолютно похуй, зависит от размера данных. И даже сжатие RLE есть. Но макака такое, конечно же, не принимает.
>>161732594 Онлайновый инсталлятор, который скачает недостающее по ходу установки или офлайновый, который все нужное содержит в себе. Если ты не знаешь, зачем тебе это, то и разницы для тебя нет.
>>161732687 >Ты же тупой как хлебушек. Может и так. Но в конечном итоге распаковывал я в гуях а не в терминале, в таком случае файловый менеджер сам вроде прочухивает, что там за архив и выбирает соответствующий архиватор. Или нет?
>>161732886 >Блять, объясните, как такое может быть сжимаю winrar-ом 10 гигов, в zip, время сжатия 6 мин, на выходе архив весит 10 мб сжимаю в rar, время 1 минута, на выходе 4 мб
>>161732940 >сжимаю winrar-ом 10 гигов, в zip, время сжатия 6 мин, на выходе архив весит 10 мб >сжимаю в rar, время 1 минута, на выходе 4 мб Ага, ага, а тред то о чём?
>>161733990 >а как анон так высчитал кол-во шагов? Мимотупой Один символ в юникоде занимает 2 байта. Берем условные 100 символов, умножаем на 2. Потом 200 символов умножаем на 2. Ну ты понел. И так пока не получим 2 (байта на символ) x 1024 (байтов в мегабайте) x 1024 (мегабайт в гигабайте) x 10.
>>161733990 Ну ты каждый раз удваиваешь количество символов. Т.е., на шаге 0 у тебя 1 символ, на шаге 1 у тебя 2 и т. д., на шаге n у тебя 2n символов. Для 10 гигов тебе соответственно нужно log2(1024×1024×1024×10) = log210737418240 = 33.321... (т.е., 33 шагов не хватит, будет 8 гигов, 34 будет много - в какую сторону округлять - дело твое).
>>161734123 Вручную попробуй разрешить ему использовать больше ядер, или как-то повысить приоритет выполнения. (не знаю как это в винде делается, но скорее всего как-то в диспетчере задач)
>>161734123 При большом желании файлы можно читать и парсить параллельно, распределяя нагрузку на все твои 4 ядра, но так как это текстовые редакторы, никому в хуй не вперлось писать такой код. Тем более в нотепаде, который по сути своей оболочка вокруг системного поля ввода текста.
>>161734147 >Что сделает d через пробел? Указывает, что ты переходишь на другой диск (логический раздел, если по-человечески), подразумевается, что путь нужно указывать абсолютный.
>>161731358 >>161731394 Я в этом всем не шарю, но кто-то предложил сделать огромный пиксель. Возможно, в битмапе на этот один пиксель приходится 10гигов текста. но такое же невозможно, да?
>>161734659 .iso - охуенная штука в этом смысле. В .iso можно ссылаться из разных файлов на одни и те же сектора и делать исошки, которые хуй скопируешь, потому что все файлы на ней весят терабайт. И никакого сжатия при этом не нужно (но можно саму исошку упаковать в .zip для большего веселья).
>>161734805 Мне все равно каким путем ты пришел к этом. Сам факт того, что у тебя хранится документ в 400 гигов вызывает недоверие к тебе, твоей личности, проводнику и твоему коту.
Блять. Я подумал можно сделать zip архив с файлом в котором символ повторяется N раз, открыть его хекс редактором, найти найти в нем N в двоичной системе исчисления и заменить его на 5 * 2^20. Не прокатило.
>>161735586 Внутри зипа во-первых размер файла в двух местах, во-вторых битовые (БИТОВЫЕ!) потоки, в которых и закодированы повторы. В Deflate LZ77 (т.е., вместо байтика пишется ссылка на предыдущий байтик в потоке и сколько он повторяется, но и сама ссылка, и счетчик повторов сверху еще хаффманом пожаты. В общем, это не хекс-редактором делается, и не в одном месте.
>>161734938 А дальше что? Что дальше было? Ты еще раз сжимал? Каков предел, после которого размер архива не уменьшается? Распаковать пробовал, сколько времени заняло?
>>161735784 Дальше произошло то, чего не должно было произойти. Никому не пожелаю познать то, что познал я. Скажу только что тысячная архивация это точка невозврата.
>>161736114 >а смысл? чтобы какой-то долбаеб скачал и расстроился? Сейчас 99% контента всего по этому принципу делается и без раздутых текстовых файлов.
сжимаю winrar-ом 10 гигов, в zip, время сжатия 6 мин, на выходе архив весит 10 мб
сжимаю в rar, время 1 минута, на выходе 4 мб