Как стать автором
Обновить

Комментарии 196

При таких ценах на HDD, имхо, архиваторы сейчас нужны только для того, чтобы объединить кучу файлов в один и переслать куда-нибудь.
Как раз для этого в этом архиваторе есть возможность прямого доступа к архиву на сайта и распаковки только выбранных файлов =)
Ну вообще для объединения кучи файлов есть tar. Архивирование должно давать выигрышь в скорости, тк жеские диски практически не развиваются в плане скорости.
У tar не всё гладко с совместимостью, для меня было большим сюрпризом, когда архив созданный под FreeBSD отказался распаковываться на RHEL.
до сих пор с кодировками там не все гладко… не определено стандартом, как и для zip.

windows-версии никак не хотят utf8 понимать
Что значит не развиваются? Отлично развиваются, новые 2Тб винты существенно быстрее 500Гб из того-же сегмента. Проверенно на высоконагруженных файловых серверах. ДА и ssd постепенно становятся массовыми.
Ну жеские диски все равно остаются узким место. Развиваются но значительно медленнее всего остального. А что за новые винты на 2 ТБ? www.nix.ru/autocatalog/hdd_fujitsu/HDD_SAS_Fujitsu_MBA3300RC_15000rpm_70978.html — у нас примерно такие. Они еле ворочаются.
Ну я не имел в виду, что они вдруг стали очень быстрыми. Важно, что 2 года назад мы покупали 500Гб, как оптимальные по цене на гигабайт, сейчас берем по аналогичным причинам 2Тб и разница в скорости на лицо. На рандомном чтении, винты конечно медленные (а те, что мы используем, еще медленее. они быстрые для больших файлов), но есть ssd, на определенных задачах их уже можно применять, возможно, скоро таки наладят надежность и можно будет применять вместо высокооборотистых винтов повсеместно.
Архиваторы нужны, конечно, но называть выигрыш в пару мегабайт, при современных объёмах винчестера «большим отрывом» это прямо анекдот. :)

А использовать по моему личному опыту стоит только zip, потому что жмёт он приемлемо, а открывается абсолютно везде, даже если пользователь специально программ не ставил никаких.
Еще бы не было у него проблем с utf8. :(
>открывается абсолютно везде, даже если пользователь специально программ не ставил никаких

Вы с мэйнфреймами от IBM работали?
А в чем проблема? Сколько не работал с AIX, все POSIX совместимое он без проблем кушал.
В AIX, насколько мне известно, изначально нет никакой поддержки .zip-архивов.
но компилятор там же есть, поэтому проблема скорее в лени, а не в операционке и тем более самих машинах.
Дело не в лени. В системах, живущих по корпоративным правилам, любые отклонения от стандартной конфигурации нередко исключены.

В таких условиях tar и gzip представляют куда более жизнеспособную альтернативу (если дело не касается Windows, конечно).
AIX не работает на IBM'овских мейфреймах. AIX это ОС для серверов на процессорах POWER. У IBM'овских мейфреймов другое железо и стоит на них обычно z/OS.
Бэкапы? Зачем мне хранить сотни гиг баз данных которые можно сильно уменьшить в размере заархивировав.
Бекапы входят в категорию «переслать куда-нибудь», так как вряд ли найдется большого ума человек, который будет хранить бекапы там же, где и рабочие файлы.
Пересылать тоже лучше меньший объем.
Спасибо, Кэп!
Незачто, вот вам бонус: затыки по каналу не реже чем затыки по HDD.
Вы об инкрементальных бекапах слышали?
И что? Их не нужно архивировать?
Что вы! Конечно нет :)
Видимо, нужно уточнить, что слышать нужно было о инкрементальных бекапах на хардлинках, когда каждая копия является полным бекапом, но содержит только изменения. Вы просто не сможете его заархиваировать, не потеряв всех плюсов. Другое дело, что можно использовать для них сжатый диск.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А больше чем большой-большой — даже в архиве можно заливать бесконечно.
Просто, если вы не можете позволить себе время заливки или резервного копирования длиной в вечность — выбирайте правильный инструментарий для бэкапов/заливок.

И архиваторы — что тары что фрярки — это не то. И дропбокс — не то.
Под задачи надо выбирать тулзы — а не увидев тулзу думать куда бы её применить.
НЛО прилетело и опубликовало эту надпись здесь
Многие люди пользуются ноутами и просто поставить туда N-терабайтный винт проблематично.

Эх, только в этом тесте сжимали .txt, .cpp, .doc, и .wav.

А на винте ноута, небось, .jpg, .avi и прочие матрёшки процентов 80 объёма занимают?
Этот архиватор — на самом деле просто оболочка над множеством других архиваторов, умеющая параллелить их по ядрам.
В этом и весь плюс, через .ini можно подключить например pacarc (packjpg + packmp3) для сжатия jpeg до 30% без потерь и сжатия mp3 до 15% без потерь. Единственная проблема в том, что этого нет из коробки (из коробки — packjpg через глючный precomp, который не даёт сжать jpeg), и соответственно просто так архив не перешлёшь никому, да и SFX тоже внешние упаковщики не упакует.
При этом автор Булат последние 9 месяцев никак не реализует эти пожелания из коробки, что несомненно бы сделало из FreeArc мультимедиа архиватор №1 среди бесплатных.
Ну может, потому он и не распространен, что «в любой момент формат сжатия может быть изменен и новые версии не смогут открыть старые архивы»? Как же так можно…

А лично мне архиваторы нужны. Именно для того, чтобы объединить тысячи файлов в 1 и закачать их на сайт скопом. При этом очень кстати хорошее сжатие и скорость сжатия/распаковки. Я пользуюсь сейчас 7-zip из-за бесплатности и кроссплатформенности. А фриарк на каких платформах работает? Поддерживается ли распаковка фриарка чем-нибудь, кроме самого фриарка? Или там версии слишком быстро меняются?
НЛО прилетело и опубликовало эту надпись здесь
>не понятно зачем нужны большие степени сжатия
С таким подходом мы бы до сих пор смотрели бы мыльное кинцо, закодированное xvid'ом, которое весило бы в 3-4 раза больше, чем рипы современными кодеками вроде h.264 или vp8.
НЛО прилетело и опубликовало эту надпись здесь
Дело не в сжатии видео. Приведу более отстраненный пример. Зачем уменьшать техпроцесс микросхем? какая разница, 32 или 22 нанометра? Постепенные улучшения никогда не вредны, места, как и производительности, никогда много не бывает.
НЛО прилетело и опубликовало эту надпись здесь
>И если однажды появится универсальный алгоритм, который быстро сможет сжать терабайт в мегабайт — отлично же.
>Чаще скорость более важна, чем процент сжатия.
С высокой вероятностью этот алгоритм будет сжимать терабайт в гигабайт за миллисекунды.
Создавая алгоритм с большей степенью сжатия, нужно поддерживать его производительность на приемлемом уровне. Поэтому с высокой вероятностью у нового алгоритма соотношение степень сжатия/производительность будет выше чем у старого, и выставив не максимальную степень сжатия мы получим тот же размер, что и у старого алгоритма, но быстрее.

Дисклеймер: вышеописанное верно, если предположить, что зависимость степени сжатия от времени линейная.
Как минимум, архив будет писать на флэшку или винт с отключенным кэшированием (что актуально для бэкапов) на 10% быстрее :)
НЛО прилетело и опубликовало эту надпись здесь
У Булата в приоритете как-раз скорость сжатия при сравнимых или лучшей с другими архиваторам стеипени сжатия.
Вы забываете, также, что немаловажную роль играет степень распространённости формата среди пользователей. zip откроется везде, а этот freearc — нигде.

h264 тоже поначалу мало где использовался, но это было кому-то нужно, вливали деньги и ни шатко ни валко формат пошёл. Причём качество отличалось довольно существенно.

Также и с техпроцессом. В это вкладывают деньги, результат заметен.

Freearc же не нужен никому. Да и выигрыш там смешной просто.
сначала ни шатко ни валко, потом, понятное дело, всё закрутилось быстро :)
Выигрыш в разы на времени сжатия — очень, очень смешно
Мне странно что он выигрывает у 7zip по скорости и при этом не заявлена поддержка мультипроцессорности.
Ну FreeArc почти целиком построен на чижих опенсорсных либах сжатия. Поэтому поддерживает мультипроцессорность в той же мере, что и эти либы. LZMA ЕМНИП 2 потока пользовать умеет.
> Архиватор он не сжимает, он объединяет файлы в один.

По-моему, такое было только на заре компьютерной эпохи, во времена распространения старинных здоровенных Unix-машин с ленточными носителями (с последовательным доступом к данным на запись/чтение). Тогда перед записью множества файлов на ленту их все сначала объединяли в единый файл, делали из набора файлов так называемый ленточный архив (tape archive) и делал это Tape ARchiver (отсюда и файлы *.tar).
А потом уже решили, что для экономии места этот объединенный tar-файл ещё можно сжать какими-то алгоритмами сжатия типа GZip, BZip2, xz, lzip. Такие пожатые tar-файлы уже получили соответствующие расширения: *.tar.gz, *.tar.bz2, *.tar.xz, *.tar.lz.

И с тех пор последующие архиваторы после древнего tape archiver'а всё же предполагали не просто последовательное объединение множества файлов, но и их компрессию. Потому как в эпоху персональных компьютеров с HDD архиваторы стали уже использовать не только и даже не столько для объединения файлов в один (что было важно при записи на ленту), а именно для компрессии и экономии занимаемого на диске пространства.
НЛО прилетело и опубликовало эту надпись здесь
Разделяется прежде всего в никсах, в самой популярной десктопной оси такого разделения не наблюдается.
И правильно делает. Можно спокойно вылизывать tar, добавляя в него плюшки типа сохранения всех прав на файлы (никсовых, виндовых, linux caps). Фиксить поведение при виде симлинков и т.д. и т.п. А потом уже сжимать наиболее подходящим алгоритмом. А разрабам алгоритмов не нужно парится тогда над всякой ерундой!
Не могу с вами согласиться полностью.

Если в архив требуется поместить разнотипные файлы, то может не быть наиболее подходящего алгоритма для все скопом. FreeArc, например, сжимает bmp файлы специально заточенным под них алгоритмом. Выбирает порядок для добавления файлов в архив таким образом, чтобы файлы с одинаковым расширением шли подряд, что повышает эффективность непрерывной архивации — tar так умеет? Для извлечения файла, находящегося в конце в tar.* нужно распаковать архив целиком, а у FreeArc можно ограничить максимальный размер блока непрерывной архивации, так что для извлечения файла из конца архива нужно будет распаковать только один блок, в который он попал.

В общем, упаковщику знать об отдельных файлах в архиве полезно, а введение дополнительных уровней абстракции всегда снижает эффективность.

Для многих областей FreeArc рулит, но если требуется хранение unix прав, ACL там или требуется жать на лету через пайпы, то тогда конечно .tar.*
IMHO объединение файлов — это упаковка.
Ну не скажите, +20% даст например возможность компаниям для бекапов закупать меньше дисков а следовательно понизить цену на свои продукты на сумму экономии. А если еще это будет быстрее происходить то можно и на серверах сэкономить.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
При таких объёмах скорость сжатия тоже играет немаловажную роль. Может какие аппаратные компрессоры уже придумали для этих целей?
Петабайтные архивы обычно живут на ленте с аппаратным сжатием, дополнительно никто ничего не упаковывает, чтобы не поиметь проблем при восстановлении.
НЛО прилетело и опубликовало эту надпись здесь
>> и 100mbit безлимитный канал стоит около $6 :)
где такие цены найти, особенно в регионах… (У меня вот за 13$ 10МБит, но это не дорого)

А так к статье-действительно уже активаторами пользуются в основном для передачи нескольких файлов в одном, эпохи, когда все архивировали, что бы освободить место давно прошли.
НЛО прилетело и опубликовало эту надпись здесь
Дарю идею как искривить пространство.

1. Берём файл
2. Считаем от него, предположим SHA, хеш, записываем изначальный размер.
3. Вуаля. Степерь сжатия космическая.

Чтобы распаковать:
1. Берём очень быстрый компьютер, много их.
2. Перебираем все возможные варинты
3. Находим тот, который подходит к хешу.
4. PROFIT!!!
Не получится. Хеш — пусть даже 1024-битный какой-нибудь, 2^1024 варианта. Размер файла — N байт, есть 2^(8*N) файлов такого размера. То есть будут коллизии в невероятном количестве (2^(8N-1024) файла размера N байт с одинаковым 1024-битным хешем).
На всякий случай все же поясню мысль — коллизии в том смысле, что пару (хеш, размер) можно распаковать вон таким количеством вариантов. Какой из них был исходный — неизвестно.
Вы так старательно на это отвечаете, как будто восприняли этот комментарий всерьёз.
По-моему, очевидную ерунду, сказанную кем-то, следует опровергать. А то кто-нибудь прочитает и поверит.
Он делает из вашего глупого камента фарс, придавая ему хоть какой-то смысл.
Из какого ещё «моего коммента»?
Простите, был напуган.
А вы вообще не знаете про коллизии, да?
Я рад что мой комментарий позволил многим почувствовать, что есть кто-то глупее них, но я знаю про коллизии и это была просто шутка.
В Днепропетровске 100 мегабит стоят 6 баксов?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Психологическая отметка в 350 рублей?! За 100 мегабит?!!! Да вы, сударь, за… кушались :)

Краснодар, 1000 рублей в месяц, 15 мегабит.
Укртелеком, АДСЛ 4/3 мегабита, Харьков. Эквивалент 8 американских долларов в месяц. Реально — около 3/2 по практическим результатам. :)
И уж по совершенно непонятным для меня причинам (в техподдержку не звонил, муторно ожидать 15 минут в очереди) нет в панели управления возможности перейти на 10/5 за 10 у.е.
Впрочем, нам с женой хватает и того, что есть. :)
И уж по совершенно непонятным для меня причинам (в техподдержку не звонил, муторно ожидать 15 минут в очереди) нет в панели управления возможности перейти на 10/5 за 10 у.е.


У вас скорее всего ограничение на порту выставлено, поэтому и более быстрый тарифный план не доступен. Прийдется все-таки дождаться ответа техподдержки и описать им проблему. Вопрос только в том, нужен ли вам 10/5, если у вас при 4/3 реально 3/2 — потянет ли линия?
А я в деревне Гадюкино плачу 1500 рублей за 4 мбита. А совсем недавно платил 3500 рублей (российских, на всякий случай) за 1.5 мегабита. Кто там, говорите, зажрался? )
Да-да, у всех безлимитки на 100 мбит. Что мне делать с 32кбит/сек с потерями? В дропбокс фильмы заливать, когда у меня порты фряшные полночи фетчатся?
Совсем забыл, 500 рублей/месяц. За 64 кбит/сек — 1000.
> в среднем он работает в 2-5 раза быстрее программ аналогичного класса (ccm, 7-zip, rar, uharc -mz, pkzip)

Внезапно, не нашёл сравнения с такими лидерами рынка, как архиваторы bzip2, gzip. Есть сравнения с ними?
Сходил по ссылке со сравнением и нашёл.
Решил скачать, собрать и поиграться:
>error: CPU you selected does not support x86-64 instruction set

Открываю мейкфайл:
>-march=i486 -mtune=pentiumpro

Ну что ж вы, в 2011 году то, или есть какие объективные причины?
«Столько всего хочется хранить на жестком диске: фильмы, музыку,»
И что, архиватор сможет ужать уже loss данные?
НЛО прилетело и опубликовало эту надпись здесь
7zip так может?
НЛО прилетело и опубликовало эту надпись здесь
Среди user-friendly архиваторов StuffIt Deluxe самый лучший по части рекомпресса уже сжатых данных — JPEG ужимает на 25-40% bit-to-bit, MP3 — 10-15% bit-to-bit, PNG — 20-50% pixel-2-pixel. Речь о собственном формате SITX.

Для более извращенных случаев используется Precomp, который ищет в файле чанки от zlib и распаковывает их для дальнейшего пожатия данных более сильными архиваторами типа 7zip, NanoZip или FreeArc.
Еще забыл добавить про SuperREP — это препроцессор/архиватор, который ищет повторы на гигантских расстояниях — многогигабайтный словарь считай (это по сравнению с 4 Мб у WinRAR). Для пакования каких-нить терабайтных логов на будущее — самое то. А работать может почти со скоростью винта, в зависимости от степени повторяемости данных.
FreeArc это умеет
Не встроенная в нем это фича. А подключается снаружи, как модуль. А автор у ФриАрка и СуперРепа одинаковый :)
Я в курсе, что подключается как модуль — но главное, что работает «искаропки» без бубна, как обычно и требуется.
StuffIT хорош, но там тоже не всё хорошо. SFX архивы не могут быть больше 2Гб, соответственно получателю надо будет отдельно ставить StuffIT Expander.
Freearc тоже может неплохо сжимать мультимедиа, я выше расписал это habrahabr.ru/post/129774/#comment_5949375. Одно плохо — Булат ленится делать это из коробки.
Булат известный специалист в области сжатия данных, спасибо за статью.
Пока авторы\пользователи\иные люди не протолкнут это в популярные дистрибутивы, будь то всякие линуксы или ZverDVD никто этим массово пользоваться не будет. Отдельные специалисты для своих задач выберут свои инструмент, но стандарт для отрасли — это то, что из коробки. Всегда так было вроде…
FreeArc больше нацелен на технических специалистов.
Помоему FreeArc уже давно используется для создания некоторых дистрибутивов игр.
пруф?
смишно.

Репаки игр это не создание дистра.
А я что-то все winrar-ом по старинке.
Проприетарные технологии — это Фу! Переходите на светлую сторону!
У WinRAR есть одно замечательное свойство, не знаю, появилось ли в других, но раньше только в нём было — можно запустить exe-шку прямо из архива, он распакует всё, что ей нужно во временную папку и всё будет ок, а вот 7-zip распаковывает только саму exe-шку и она, естественно, валится.

ЗЫ: я лицензию купил.
Даже стандартный виндовый zip так умеет.
Да, но он не умеет rar открывать.
НЛО прилетело и опубликовало эту надпись здесь
И что? В смысле, вы читали дискуссию выше или отвечаете только на последний комментарий?

Речь идёт о том, что WinRAR, в отличии, по крайней мере, от 7-zip (другие не пробовал) позволяет запускать программы прямо из архива, без предварительной распаковки куда-то.

Причём здесь, кто умеет открывать rar?
Создай solid, оспаде. xD
В никсах такая возможность явно лишняя — никто так не делает в здравом уме!
У каждого есть плюсы и минусы. Среди последних, например, распаковка в системный темп при драг-н-дропе, независимо от места назначения (хотя это проблема винды, кажется). Я на виндах юзаю Тотал с плагинами 7z и других «архивов» типа iso, msi и почти не встречаю проблем (хотя и тут они есть).
(Win)RAR хорош не только интерфейсом (который, имхо, в среднем проще и удобнее конкурентов), но и возможностями самого формата и достаточно неплохой степенью сжатия (малопопулярные реализации замены алгоритма deflate в ZIP на какую-то экзотику не в счёт)
На мой взгляд он хорог оптимальным соотношннием степени сжатия и потребляемых ресурсов по дефолту.
Честно купленным, наверняка…
да нет, напоминает мне регулярно, что через 40 дней я его должен удалить.
НЛО прилетело и опубликовало эту надпись здесь
куда там промышленных, максимум за архивировать десяток файлов, чтобы не передавать по одному
НЛО прилетело и опубликовало эту надпись здесь
А проект вообще развивается? А то версия FreeArc 0.666 20 мая 2010 г. вышла. Как бы скоро полтора года версии.
НЛО прилетело и опубликовало эту надпись здесь
Должен уточнит последняя версия FreeArc 0.67 alpha (18 Марта 2011) полугодовалой давности. Хотя до этого почти каждый месяц были какие то изменения в версиях.
И интересно планируется ли 64 битная версия и будет ли она результативнее своего 32 битного собрата.
НЛО прилетело и опубликовало эту надпись здесь
Какой устрашающий номер версии!
Видимо автор не суеверен))
А между тем… то, что она последняя, наводит на мысли.
Не могу понять, на какие мысли такого ценителя русского языка, как вы, в данной ситуации наводит слово «последняя». Или вы тоже из адептов слова «крайний», которые не знают, что в русском языке «последний» — не только «last», но и «latest»?
А где UHA? Где bz2?
Извините, а по каким показателям FreeArc первый? Только потому что его поставили на первые 3 строки? Если по скорости, то я вижу 1 претендента, который быстрей жмет и разжимает. Если по степени сжатия, то таких уже несколько. Или там надо перемножить % на секунды и получить попугаев?

Сам юзаю 7zip. Попробовал FreeArc. Взял мусорную папку размером 384Мб с 2221 файлом и 270 подпапками. Размеры файлов от 1Кб до 17Мб. Файлы от txt'шников до dll'ок и exe'шников.

7zip сжал за 2:17, разжал за 0:27, архив получился 186Мб.
FreeArc сжал за 1:51, разжал за 0:21, архив получился 187Мб.

Win7, Intel Core2Duo 2.13ГГц, 3Гб ОЗУ 800МГц.

Судя по приведенной вами таблице, при лучшей степени сжатия FreeArc сжимает в 2 раза быстрее. А при худшей в 7 раз! Что-то я не заметил такой разительной разницы. Степень сжатия примерно одинаковая получилась (на стандартных настройках), разница по времени 19-23%.

Но самое неприятное: а чем разжимать *.arc? *.7z поддерживается уймой архиваторов. Придется создавать sfx?
Ну как же, по показателям в приведенной таблице. И фиг с тестами thg.ru, поместившего 7zip на первое место, а FreeArc на 4, сразу за WinRar'ом. Куда уж там до KGB archiver(PAQ), WinRK… главное что «в данный момент по эффективности все же лидирует», ага.
Ну и правильно что «фиг с ними» — дайте ссылку на эти тесты и укажите почему их оценка лучше той, которая приведена в посте. Я FreeArc использую — и впрямь жмет заметно быстрее конкурентов.
И чем оценка лучше той что в посте? Используется не последняя версия FreeArc, для двойного проигрыша по времени сжатия 7zip надо или очень тщательно подбирать набор данных или облажаться при измерениях.
KGB 1.1 86878458 — 1133сек
FreeArc 81234951 — 24сек
KGB 1.1 75341375 — 7810сек

комментарии излишни =)
Настройки обоих архиваторов?
Написал же «стандартные». Простые пользователи не будут разбираться в аббривеатурах "-m3", "-cDp" и т.д. Да даже если менять настройки, неужели он начнет лучше и быстрее жать? Это как-то попахивает формулой «КПД>100%».
Для простых пользователей есть выпадающий список с именами, за которыми скрывается строка настроек к архиватору. Естественно или быстрее или лучше. Как всегда =)
Если в нем есть разбиение по томам с возможностью создания sfx, корпоративные пользователи скажут очень большое спасибо (не успел поставить чтобы посмотреть).
Архиваторы имхо нужны только для таких случаев:

«Все картинки (секвенции) лежат тут: site.ru/folder/...
Вместо точек (...) вставьте имя первого файла sc_010001.png
Чтобы открыть все 199 картинок меняйте в ссылке номера файлов
от sc_010001.png до sc_010199.png»

Хотя помню времена, когда инсталляторы игрушек я заботливо складывал в виде архивов в отдельную папку…
И подбирал настройки размера словаря WinRAR-a и радовался, когда из-за этого выигрывал килобайт 600 =)
А я как лох peazip использую везде, может пора уже отвернуться от него…
Я каждую новую версию PeaZip ставлю и надеюсь, что уж в этой-то версии они, наконец, сделали нормальный настройщик контекстного меню. Но, видимо, моим надеждам сбыться так и не суждено :) Каждый раз сношу через 5 минут.
PeaZip не архиватор, а гуявая морда для консольных архиваторов.
После того как в винде появилась поддержка VHD необходимость в отдельных архиваторах прорала.
Если мне например нужно «слить» 100500 файлов в один, я создаю новый динамический VHD на 2 ТБ.
Кстати из-за того, что он динамический, на диске пустой VHD-контейнер «совсем мало» байтов.
Подключаю его. Создаю раздел NTFS, ставлю галочку «сжимать для экономии места».
когда размер контейнера достигает 4 ГБ, то больше файлов туда не добавляю.
А еще в винде есть сжатие на разделе, да же создовать ничего не надо.
но, в этом случае нельзя избавиться от кучи файлов, со всеми вытекающими
Для этого есть DEL :)
real-time сжатие разделов — это уже атавизм, непонятным образом сохранившийся со времён DOS (вспомним DoubleSpace)
Да-да, именно поэтому для ускорения загрузки рекомендуется именно оно
Конечно, куда кошернее ручками все жать и распаковывать каждый раз, когда понадобится.
не вижу смысла сжимать то, что не требуется сжимать
Вот для этого и используются контейнеры виртуальных дисков, чтобы внутри них хранить несжатые файлы.
Надо его сравнить с lrzip
Помимо чисто технических характеристик, таких как качество алгоритмов сжатия у архиваторов имеет большой значение такой показатель как «раскрученность». Могу с уверенностью сказать что в последние годы 7zip стал достаточно популярен для того чтобы не вводить в ступор хотя бы тех.персонал компаний. Ведь наиболее частое применение архиваторов — упаковка файлов для приложения к электронному письму (в том числе и с разбиением на тома), дистрибуция различного контента, ведь у архиватора помимо функции сжатия есть еще функция проверки целостности архива, что крайне важно для обеспечения гарантии целостности содержимого самого архива. Емкость современность винтов и скорость доступа в Интернет не смогут обеспечить быструю гарантированную проверку целостности скажем пары-другой тысяч файлов как единого целого. Так вот при таких задачах распостраненность архиватора играет ключевую роль — если вы пришлете файл партнеру, который знать не знает про ваш архиватор, то в лучшем случае он просто попросит вас переслать «испорченный» или «какой-то странный» файл заново, но уже в другом виде.
ушел качать, спасибо!
>FreeArc, кстати, как и 7Zip, бесплатен и у него открытые исходные коды.
ага, если б эти коды ещё и собирались, вообще б было классно
НЛО прилетело и опубликовало эту надпись здесь
А почему сравнивают norm сжатие 7z с x сжатием Arc?
ТС привёл не все результаты и не полностью рассказал, что же сравнивалось в данном тесте + решил попиарить архиватор (есть за что, но не надо же так явно-то). Сходите на упомянутый сайт и посмотрите все результаты — сразу станет понятнее ;)

А фразу «По результатам одного из самых авторитетных тестов FreeArc занял три первых места» следует читать как «По результатам одного из тестов FreeArc занял три первых места в одном из видов синтетических тестов на фиксированном наборе тестовых данных»
Так следует читать любую отсылку к тестовым сравнениям.
Я видимо тоже привык автоматом так читать. Поэтому и не уточнил =)
Ваш архиватор относительно быстро сжимает, но очень медленно разжимает. Странно, и непонятно куда это можно применить.
НЛО прилетело и опубликовало эту надпись здесь
Да, нормальный вариант. Но здесь, конечно, хотелось бы стабильного формата архива :)
Вырубить принудительно симметричный алгоритм PPMD — будет похуже сжимать тексты, но распаковывать быстро. Сейчас у FreeArc основное массовое применение — инсталляторы.
Удивляюсь я: еще несколько лет назад многие из нас сидели на модемной связи (да-да, когда для многих скорость 56 Кбит/сек на скачивание была вообще пределом мечтания и по сути недостижимой, ввиду качества линии, величиной), и мы с вами же экономили каждый байт как могли, хотя винты на тот момент были уже приличные по размеру. Сегодня те же самые мы с легкостью стали вести расчеты размера уже не в мега-, а в гигабайтах, и удивляемся личностям, стремящимся сжать файл на несколько тысяч байт сильнее.

Я, конечно, понимаю, что террабайт диска (по вполне бросовой цене) в домашнем компе уже никого не удивляет, как и 100 Мб линия связи домой за 500 руб в месяц, но почему-то за дебатами забываем о том, что бывают (все еще!) слабые линии связи, бывают лимиты на размер приаттаченных файлов, бывают архивные копии — и что всем этим, часто отнюдь не домашним задачам, требуется сжатие и/или сохранение нескольких файлов в один том.

Так и представляю себе системного администратора, уехавшего в Тьмутаракань, и через худосочный GPRS качающий нужные ему для подъема сервиса файлы — скажем, если файлы «на том конце» окажутся не запакованными, и качать ему придется этак не 20 минут, а 2 часа, мы вряд ли услышим из его уст восторженную оду дешевизне жестких дисков.
Моим вкладом в проект FreeArc стала оболочка wArc для его консольного варианта, которую я написал на .Net.


Поправьте инсталлятор — на моей машине установлен .net 2.0, 3.5 и 4.0, но установщик считает, что их там нет и отказывается ставиться.
хаскель медленный и академический!
Как видно FreeArc опровергает это устаревшее утверждение.
я всё забываю что здесь нельзя так тонко, я так скоро совсем не смогу посты писать =\

а вообще сталкивался не понаслышке с этим языком, примерно представляю преимущества и недостатки
Кого сейчас интересует пара % сжатого размера?
Если у вас логов (почти бесполезной информации до момента как она позарез понадобится) пара терабайт, то разница в десяток гигов еще как интересует.
НЛО прилетело и опубликовало эту надпись здесь
Можете нудеть сколько угодно, что это не мэйнстрим, и что офисному планктону ничего не нужно кроме зипа и терабайтных винчестеров. А я вот пойду прикручу его себе к ТоталКоммандеру.

Спасибо за статью.
Заглянул я в папку trunk с сырцами и малость ужаснулся творящемуся там бардаку!
Ну так версия пока альфа. Думаю, Булат сейчас много эксперементирует, поэтому все так некрасиво.
У меня даже в самых лютых экспериментах порядок есть хоть какой-то в билде и его структуре — это банально дело привычки!
… сказал автор вечной альфы :)
Между прочим, в скриптах сборки там как раз порядок царит более менее.
НЛО прилетело и опубликовало эту надпись здесь
Творческий беспорядок.

Да, интеграция с cabal была бы очень кстати.

Код тоже весьма самобытен, у многих функций нет сигнатур. GHC наверное обливается предупреждениями.

Но это ерунда, главное весь этот гигантский функционал работает. А превести к упорядоченному состоянию постепенно не так уж и сложно.
*привести
Тоже заглянул. Согласен, полнейший хаскель там.
Что со всех точек зрения лучше, чем полнейший С++
НЛО прилетело и опубликовало эту надпись здесь
Думаю что эта функционалнось обязательно добавится сразу после появления порта под CP/M. Т.е. скоро.

Что? Вы говорите сначала хаскель спортировать надо? Жаль. Значит не скоро.

Хотя нет, не жаль. Ибо не UNIXвэй был бы.
НЛО прилетело и опубликовало эту надпись здесь
А вы в серьёз интересовались поддержкой 100500летнего формата .arc?
Извините, не ожидал.
У Вас регистр слова Default неправильный. www.freearc.org/ru/Default.aspx вполне рабочая
Интересно. Сайт на апаче, а *.aspx намекает на .NET. Там Mono что-ли или шифруются просто?
Не у меня, а у автора статьи. Ссылка из заголовка.
Статус кво за старым добрым зипом, открывается даже на кофеварке. А, поскольку, нет острой необходимости в степени комперссии, за ним и останется
FreeArc, кстати, как и 7Zip, бесплатен и у него открытые исходные коды.

Было бы замечательно, если бы эти исходные коды выложили на Github.
Жаль, что на версии 0,666 продукт перестал обновлятся, хороший архиватор
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории