Архиватор 7-Zip отлично справляется со своей задачей — эффективно сжимать данные. Его можно назвать «швейцарским ножом» в мире архиваторов. Он поддерживает разные алгоритмы сжатия и большое количество форматов данных, таких как ZIP, gzip, tar и RAR. Отдельный плюс — в том, что архиватор свободный.
Первая версия 7-Zip увидела свет 18 июля 1999 года, за относительно короткое время архиватор смог стать очень популярным. Относительный недостаток 7-Zip — наличие лишь версии для Windows (официальный клиент). Но сейчас, спустя всего 22 года, появился и вариант для Linux, официальный билд от разработчиков.
Выпущен релиз под Linux на этой неделе. Версия 21.01 доступна как для Linux, так и для Windows. На сайте разработчика есть варианты для разных систем, включая 32-bit, 64-bit, x86 и ARM.
Linux-версия получила не меньше функций и возможностей, чем Windows-релиз. Единственное: пока — с 7-Zip можно работать лишь в командной строке, графического интерфейса нет. Возможно, его выпустят еще через пару десятков лет, кто знает.
Конечно, кроме официальной версии, есть и неофициальные билды под Linux. Наиболее известен p7zip, он в ходу уже несколько лет. Разработчик архиватора знает о нем, и в релизе говорится, что «официальный билд похож на p7zip, но не идентичен ему». Кстати, Игорь Павлов выпустил официальную консольную версию 7-zip для Linux вместе с выпуском версии 21.01 для Windows в связи с тем, что проект p7zip не получал обновлений уже пять лет. Возможно, если бы не этот факт, официального билда архиватора не было бы до сих пор.
Что касается новой версии 7-zip для Windows, то, как всегда, разработчик добавил ряд улучшений и исправлений. Поправлены баги, улучшена поддержка ARM64.
zenkov
Меня и gzip устраивает, а если нужно что-то сильней сжать, то zstd
FFiX
gzip не архиватор, а утилита для сжатия и распаковки, как и zstd. Архиватором в случае их использования обычно является tar.
7-zip же всё в одном, в этом от аналогичен arj, rar, ace и прочим утилитам, в основном популярным под Windows.
zenkov
> gzip не архиватор, а утилита для сжатия и распаковки, как и zstd. Архиватором в случае их использования обычно является tar.
Как много дистрибутивов Linux вы знаете в составе которых нет tar?
Catslinger
А при чём тут это? Tar примитивен. У него нет оглавления. Чтобы просто посмотреть, что в нём лежит, надо тупо распаковывать всё.
Zanak
Может быть потому, что tar создавали для записи данных на магнитную ленту, и его задача не архивировать, а обеспечивать непрерывный поток данных для записи, поэтому он и примитивен. Он не является архиватором, в привычном нам понимании, потому как ни чего не сжимает.
А вот gzip как раз сжатие выполняет, и поэтому часто работает вместе с tar.
Catslinger
Так о том и речь, что какого фига, спустя 40 лет, tar до сих пор является основой большинства способов архивации и множества пакетов, если он для этой задачи не предназначен, и плохо справляется. И нельзя сказать, чтобы альтернатив не было. Но все пользуются tar потому, что все пользуются tar, и все будут пользоваться tar потому, что все будут пользоваться tar. Железобетонный аргумент.
saboteur_kiev
нет, речь не о том. tar+gzip самодостаточны, потому что работают с потоками, что обеспечивает отдельный отличный функционал. Может быть сейчас не все используют магнитную ленту, но в линуксе есть и другие устройства, с которыми можно работать напрямую и сразу редирекить что-то в tar/gzip
Catslinger
Для сжатия образа диска tar не нужен. Папку с файлами на вход отправить через шелл нельзя, поправьте, если не прав. Получается, в двух самых бытовых случаях возможность, как вы сказали, «работы с потоками» не нужна. А в нишевых случаях всегда можно продолжать им пользоваться, никто ж не призывает выкинуть tar из дистрибутивов. Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами. Настало уже время перейти на что-то более умное.
rPman
Архивы tar чаще распаковывают чем запаковывают.
Потокового функционала мне более чем достаточно, например я пользуюсь — распаковка архива одновременно со скачиванием его по ссылке, без сохранения промежуточного.
каждый инструмент нужно использовать там где он подходящий, если надо я и 7z использую, и образ диска с файловой системой, поддерживающей сжатие, и т.п.
PowerMetall
Эх, вспомнил как я, будучи совсем юным студиозусом, распаковывая огромный по тем временам архив через WinRar, как-то раз раз дико удивился двум вещам:
Но, к слову, тогда быстро пришло некое осознание того, что «не все так просто в датском королевстве», я начал это дело копать, ну и в итоге это стало частью одного из кирпичиков знаний
sumanai
Ну да, 7zip распаковывает в Temp, а потом почти столько же копирует на другой диск, если это делать перетаскиванием. Если через интерфейс указать путь, то распаковка идёт сразу в нужный каталог.
geher
Это в каком смысле?
Если имеется ввиду графическая среда, то папка с файлами нормально перетаскивается в архив tar (со сжатием сверху или без) в Ark (в KDE).
Возможно, что в других графических средах (Gnome, Mate, Fly) оно тоже есть.
Если имеется ввиду какой-нибудь bash, то нормально принимает на вход папку и всю ее загоняет в архив.
В mc оно тоже неплохо добавляет папки в tar.
Если имеется ввиду конвейер, то какой архиватор может?
Оно, конечно, давно p7zip.
Но раз на два не приходится. tar и gzip в любом дистрибутиве линукса предустановлены (по крайней мере пока без него не видел), а другие архиваторы-разархиваторы (даже unzip) могут отсутствовать (встречал такие случаи, особенно на серверах). Это как zip во всех остальных случаях — средство гарантированного понимания.
Catslinger
Это в смысле что мы говорили конкретно о bash pipe. Ими и нельзя передать папку на вход tar. Поэтому способность tar получать данные на вход через pipe не имеет практической пользы при запаковке папки с файлами.
У p7zip тоже свои проблемы есть. Софт почти не развивается. Полгода назад в Арче самая свежая версия была от 2016 года. Как сейчас — не знаю. Алгоритм сжатия юзером не заменяется, а алгоритмов новых уже придумали и ещё придумают.
FFiX
В арче сейчас этот форк.
Catslinger
О, свежачок, хоть zstd добавили — приятно.
saboteur_kiev
Ну очень даже имеет смысл, например в случае, когда вы хотите с удаленной системы в которой файловая система ридонли, взять какой-нибудь каталог и скачать его архивом. Берешь каталог, через find, пихаешь его в tar/gzip, кидаешь прямо в ssh а с той стороны прямо из ssh распаковываешь. И нигде не нужно создавать сам файл архива — ни там ни тут.
Вы конечно скажете про rsync/scp, но это уже каждый файл отдельно.
Catslinger
Можно пример команды на отправку, а то я честно не понял, о чём речь. Мой стиль баш-фу не чист: использую parallel k месту и не к месту…
DaemonGloom
Простейший вариант:
Упаковываем файлы, но не пишем архив на диск, а сразу шлём его по ssh туннелю, где этот архив на лету распаковываем в папку. Ни одной промежуточной записи не требуется.
Catslinger
Так и я могу. Пусть покажут, что сказали: файлы на запаковку в tar подаются через pipe.
saboteur_kiev
Ну так сделай тоже самое через zip?
Ну или вот простой пример:
Ну например банально:
mongodump blablabla --archive | tar
Stinkynnov
Для галочки.
За все реализации не скажу, но GNU tar вполне понимает список файлов в stdin через -T
find . | tar -cvf /dev/null -T -
saboteur_kiev
Так так и не сжимает, он «каталогизирует»
Смотря что вы имеете ввиду. Список с файлами легко, через тот же find, но ведь папка — не является устройством и следовательно потоком.
так таром и не сжимают, сжимают gzip, который с tar в хорошей синергии именно из-за умения работать с потоками.
А для просто сжатия — есть обычный zip/bzip/ну и наконец 7zip. Просто перейти на что-то более умное можно будет тогда, когда оно доступно в каждом дистрибутиве из-коробки. RAR в этом случае не подходит — платный (а зря), а 7zip бесплатный, и я новости радуюсь.
FenestramDeveloper
«Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами. Настало уже время перейти на что-то более умное.» — при выборе ПО первым критерием (после очевидных, что ПО должно работать и иметь документацию хотя бы на минимальном уровне) беру «ПО не должно быть умным». Умным должен быть пользователь.
Тар-ом пользуются для архивации, потому что он как раз хорошо подходит для этой задачи, во всяком случае, не страдает таким идиотизмом (см ниже), как как при распаковке из рам-диска на рам-диск сохранять промежуточные файлы на системном жёстком. Да и производительность при поиске файла тоже неплохая, так как он перескакивает от заголовка к заголовка, считывая с диска минимум информации. А вот со сжимающими утилитами проблема есть. Здесь много чего следует усовершенствовать.
А что касается сжатия… следовало бы сравнивать с возможностями сжатия на уровне ФС. Это удобнее, так как не надо ничего запаковывать/распаковывать, это может быть быстрее за счёт использования инструментов уровня ядра, и это может дать большее сжатие за счёт большего числа файлов. Надо проводить эксперименты.
sumanai
Эм, это от формата зависит примерно никак.
Эм, все известные мне файловые системы со сжатием сжимают отдельные файлы поблочно, и тут никак не поможет то, что файлов много, скорее даже помешает.
bonta
А еще через tar очень удобно размещать файлы проектов для создания порта из linux в windows.
Например я не помню команду создания символических ссылок в windows. А в проекте — они используются. Просто делаю tar в linux, распаковываю его раром или семьзипом в виндовс — и имею каталог проекта с рабочими символинками, которые создали программы а не я. Если же копировать из линукса в винду средствами ФМ то не получается создать символинки, т.к. нужно обладать правами администратора. Может и можно как-то создать коннект между двумя операционками с админ-правами на винде, но мне проще вот через тар, чем что-то гуглить ради того что потребуется несколько раз в год :)
bonta
Пользуются потому что удобно.
Например я использую tar для создания резервных копий дерева исходников. никакие гиты не заменят этот способ, т.к. гит удобен когда кладёшь в него что-то завершенное (фичу, фиксобаг, готовый таск). А на пути к этим этапам очень удобно сохранять рабочиепромежуточные версии (чтобы не убить, и не откатываться потом до последней рабочей версии из гита) — используя tar. Он внушат уверенность что после восстановления из tar — все меданные создания/изменения файлов будут оригинальными. Если же делать эти манипуляции через обычные средства (скопировать — вставить), то как минимум дата создания файла поплывёт. А эти данные между прочим помогают ориентироваться, не плохо помогают. И нет нужнды для таких операций, при дешевом дисковом пространстве — тратить вместо 20 секунд помещения в tar — например 80 на сжатие каким-то алгоритмом.
И даже если не брать профессиональную сферу, то именно в сохранении метаданных нахожу удобство tar, например резервное копирование семейных фотографий (где кроме jpg, еще и raw, не сжатое mov).
Никакие облака для этого не годятся, так же и тратить время и киловатчасы на сжатие терабайтных директорий — ну такое себе.
Просто подключаешь диск, и создаёшь архив tar на диск для резервных копий. И если основной диск умрет — потом можно восстановить и метаданные останутся как были, фотографии снятые в 2000х, так и будут иметь «время создания», «время изменения» — и вот это очень ценно. Когда прожил много лет, и накопил хороший личный-медиа-архив — вот эти вот «время создания 2002.12.31» — не менее ценно чем само содержимое фотографии.
И да, концептуально tar именно архиватор, и *.tar — это файлы архивов. К архивам в общем нет требования чтобы они были сжатыми. В тех же zip,rar можно паковать без сжатия. Более того в rar (единственном из всех) есть возможность создать архив с информацией для восстановления, при выключенном сжатии — архив получится больше чем размер оригинальных данных.
Очень полезная функция, например если потерялась одна/несколько из дискет — то при хорошем процентном (определяется в настройках) соотношении информации для восстановления — все данные восстановятся, как будто бы и не терялось ничего. В современном мире чуть менее но актуально, пример — умирающий носитель информации.
Zanak
не нужно сгущать краски. связка tar+gzip давно не является стандартом, как вы давно уже не жмете в arj или zip. rpm или deb жмут в lzma, например, на сколько я знаю. другими дистрибутивами пользуюсь редко, поэтому ни чего не могу про их пакетные менеджеры сказать.
если под nix системами до сих пор этот тандем и используют для обмена файлами, то исключительно потому, что это работает на подавляющем большинстве систем, не зависимо от опций установки ОС. пока это работает, этим пользуются, особенно, когда требуется раздать файл +100500 тысяч человек. перестанет работать — перестанут пользоваться. ни кто не заставляет вас отказываться от 7-zip, если вы точно знаете, что ваш коллега/знакомый/друг точно сможет этот архив прочесть.
FFiX
Функция сжатия в архиваторе опциональна, т.к. основная функция архиватора — собрать кучу файлов в один. tar и cpio это умеют и они оба считаются архиваторами.
Другие архиваторы (вроде 7-zip или старого доброго zip) пошли дальше и в них сжатие (и даже шифрование) является стандартной функцией.
Karpion
Как ни странно — такого примитива более чем достаточно для очень большого круга задач. Например, когда из репозитория скачивается программный пакет для установки в систему — никому и в голову не приходит отдельно просматривать оглавление: пакет после скачивания весь разворачивается в нужное место.
Вот чего действительно не хватает в мире архиваторов — так это программы, позволяющей использовать архив (возможно, с компрессией) вместо (в роли) папки с файлами. Причём не монтировать его (это доступно только админу), а предоставлять доступ на уровне приложения, через библиотеку. Т.е. чтобы данные заливались на сервер и хранились там в компактном виде.
Разумеется, предполагается, что данные меняются крайне редко, а вот читаются довольно часто.
kocherman
Вы только сейчас проснулись? Webpack, initramfs, squash, cpio, iso-образов вам мало?
fshp
С чего бы?
suid, polkitd, fuse. Куча вариантов.
Ну и в виде программного интерфейса это лет 20 уже существует
https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html
unC0Rr
physfs? В любом случае, все технологии, перечисленные в ответах к этому комментарию, существуют не один десяток лет.
commanderxo
wormball
tar --help
BubaVV
Вот тут могло быть и -H
saboteur_kiev
-H, -h вместо --help могут привести к неприятным последствиям
Maccimo
ha, да вы археолог!
JerleShannara
pkunzip.zip, от создателей ha.ha
Oxyd
Какие-то фидошные шутки в комментах. Борода которых раз в десять длиннее моей. ;-)
FFiX
Ну я ace довольно активно пользовался в своё время. До выхода какой-то из версии rar (2.90, кажется) он мне очень нравился.
arj тоже удалось застать.
enamchuk
WinAce был особенно хорош, т.к. умел хорошо сжимать файлы и пиликать спикером, когда нужно было заменить дискетку при создании многотомного архива.
zuek
Я бы к археологии скорее ain отнёс — не многие его застали, но жал он круче любого архиватора той эпохи, и был быстрым.
saboteur_kiev
А если вам прислали архив в 7zip?
Нужно понимать, что 7zip стал стандартом дефакто для подавляющего большинства windows-пользователей, и он умеет не только в zip, но и в 7z, который на линуксе распаковать нечем.
И это очень хорошо, что теперь 7zip официально доступен на обеих платформах.
Вдобавок, научитесь не путать потоковое сжатие gzip и архиватор.
vyo
На Linux нечем распаковать 7z? Вот так новости.
p7zip
(7z
команда — это он) уже не первый год вроде как есть, используемый многими gui надстройками для архивирования и разархивирования без проблем. Но и официальная поддержка это, конечно, неплохо.saboteur_kiev
Я вот недавно столкнулся с тем, что на rhel7 сходу zip не установлен, и его нужно устанавливать, что вызывает проблемы, если нет прямого доступа в продакшен.
И это еще хорошо, что он в официальном репозитории остался.
site6893
в современном мире в таких холиварных вопросах всегда упускается одна очень важная деталь. Многопоточность!
gzip — однопоточный и всегда будет проигрывать архиватору кторый умеет в многопоточность в разы.
вопрос к Tyooo: официальный 7-zip на линуксе в многопоточность умеет?
rPman
Есть мультитредовые версии разных компрессоров, pigz например для gzip, производительность у разных может кратно отличаться в зависимости от настроек
saboteur_kiev
суть однопоточности в gzip, потому что он на вход может принимать не файл, а именно поток. И компрессировать именно его, а не целый файл. В результате, пока другие архиваторы ждут целый 10-терабайтный файл, gzip уже сжимает и отправляет сжатое дальше.
Ну и плюс pigz
DrPass
Ну как бы да, но с другой стороны, в stdin он себе обычно как раз файл и получает, и вот эта unix-style архитектура оказывает ему медвежью услугу. Другие архиваторы с произвольным доступом покромсали файл на блоки и в четыре, восемь потоков обработали, а этот может только последовательно, и никак иначе.
saboteur_kiev
stdin это не файл, а блочное устройство (как и многие файлы) =)
1. Чтобы покромсать файл на блоки, его надо вычитать, а если это не файл, а лента или любое другое устройство последовательного чтения, то несколько потоков уже и не всегда выгодно.
2. Какие другие архиваторы с произвольным доступом? Почти все другие архиваторы, ради более быстрого сжатия, стараются анализировать блок побольше (а то и файл целиком), создать словарь, и только потом уже сжимать.
(Именно поэтому алгоритм, компрессии использующийся в gzip, быстро стал поддерживаться многими модемами, а потом и различными другими устройствами)
3. Уже несколько раз упомянули про pigz, если это необходимо, который многопоточный, при этом обратно совместим с gzip
DrPass
Как минимум, выгодно если скорость чтения с устройства выше, чем скорость сжатия.
Ну и даже создание словаря — вполне себе распараллеливаемая задача. Gzip же вообще такой возможности лишён :)
Tyooo Автор
Собственно ответ уже был, лишь повторюсь, что всё зависит от компрессора. gzip сам по себе однопоточный, но у него есть мультипоточная реализация pigz.
А так поддержка ключей в 7-Zip для Linux есть:
-m{Parameters}: set compression Method
-mmt[N]: set number of CPU threads
-mx[N]: set compression level: -mx1 (fastest)… -mx9 (ultra)
FFiX
Исходников Linux-версии тоже (пока?) нет. А автор по ссылке с официального сайта на вопрос о замене p7zip в будущем пишет, что не работает с Linux и ему будет сложно заниматься пакетированием всего этого добра.
dartraiden
Насколько я понимаю, Игорь обычно не публикует исходники до релиза.
drWhy
Отличный архиватор, жаль что в Windows не интегрируется сам, как это делает WinRAR.
Ещё, кажется, нет возможности добавления данных для восстановления архива.
По скорости и степени сжатия превосходил WinRAR, раньше по крайней мере.
Ну и бесплатность добавляет популярности.
Спасибо разработчику.
hottabxp
Что вы имеете в виду под «в Windows не интегрируется сам»?
drWhy
Интегрируется в контекстное меню, но не регистрируется сам в качестве приложения по умолчанию для соответствующих типов файлов. Т.е. с точки зрения многих пользователей архивы открывать всё ещё нечем.
Shatun
Не помню умолчания при установке, но можно зайти в tools->options и там поставить галочки на все типы файлов которые нужны.
drWhy
Да. А у WinRAR этого не нужно делать отдельно. В остальном — прекрасный продукт.
Lev3250
Насколько помню, если установку принудительно запустить под админом, то умеет. Или я что-то путаю
psycho-coder
Верно, под админом надо делать.
mSnus
А Shift-RClick — "открыть с помощью.." — "всегда открывать файлы такого типа" не катит?
drWhy
Объясните условной бабушке данные действия по телефону. Почему просто не сделать привязку сразу при установке?
DirectoriX
Потому что если каждое приложение при установке будет перетягивать ассоциации на себя, у вас будет анархия. Знаете, как сильно бесят обновления Windows, после которых она в очередной раз предлагает использовать Edge при открытии HTML-файлов? Зачем она это делает, я ведь уже выбрал Firefox как браузер по-умолчанию и как приложение для открытия HTML? А то, что вы предлагаете, привело бы к привязке Edge, ведь он же был установлен!
drWhy
Но браузеры это настойчиво делают и будут делать, по политическим соображениям. И есть причины, почему у Вас в системе установлено более одного браузера.
А станете ли Вы устанавливать более одного архиватора? Понадобится ли условный WinRAR, если 7-Zip уже умеет распаковывать все необходимые форматы и наконец-то научится нормально интегрироваться?
mSnus
У меня большинство архивов открывается Total Commander, 7-zip для редких случаев и shell menu как раз
drWhy
Аналогично, в большинстве случаев использую для распаковки Far. Сжимаю всё же архиватором обычно.
DirectoriX
Вот вам пример: у меня есть программа для просмотра JPEG-файлов, «Фотографии» (встроенная в Windows). Я ставлю Photoshop, который умеет редактировать JPEG-файлы. Он тоже должен прописывать себя как приложение по-умолчанию для JPEG? Чтоб вместо «Фотографий» у меня открывался условный Photoshop? Или «вы не понимаете, это другое»?
DaemonGloom
Photoshop, скорее всего, прописался по кнопке "Изменить" в контекстном меню JPEG-файлов. Перезаписав Paint, который был там по умолчанию.
drWhy
«Фотографии» в Windows 10 весят как Photoshop десятилетней давности, не умея примерно ничего, и загружается 15 секунд. Поэтому у меня заменены на IrfanView, весящую на порядок меньше и умеющую всё. Конечно, IrfanView зарегистрирована как стандартный просмотрщик для всех типов изображений.
Редактор по умолчанию необязательно привязывать, обычно. Но tastes differ, как говорят англичане.
mistergrim
DrPass
Скажите, а зачем вам упаковывать именно в RAR, если есть другие форматы?
mistergrim
Даже не знаю, как ответить на такой вопрос. Наверное, затем, что мне нужно?
DrPass
Это звучит примерно как «я иду покупать молоток с синей ручкой, потому что у меня дома только с зелёной, а мне нужно забивать молотком с синей»
mistergrim
Ну если для вас архиваторы различаются только цветом, тогда извините.
DrPass
А вы, чем ёрничать, лучше на календарь гляньте, какой сейчас год. Разница в степени сжатия давно помножена на ноль. Смысл информации для восстановления — тоже помножен на ноль, т.к. дисков, у которых могут отдельные сектора с данными посыпаться, просто нет — у флешек такого вообще не бывает (ну, кроме случая, когда вы записали на неё данные, которые вы решили прочитать лет через десять), у винтов теоретически бывает, но настолько редко, что нет смысла заморачиваться. По сути, самый удобный формат архивации вообще обычный zip, т.к. его поддерживает всё, что угодно, и вы будете уверены, что и вы, и любой ваш контрагент его всегда сможет открыть. Так что да, они только цветом различаются, ну ещё и скоростью архивации. И в этом плане и RAR, и 7-zip явные аутсайдеры.
mistergrim
DrPass
Даже если у вас это и произойдёт один раз на несколько тысяч операций, вам намного будет проще ещё раз свой файл туда записать, нежели каждый раз добавлять туда избыточную инфу для восстановления.
UER на HDD, это в общем случае не безвозвратная потеря данных, обычный винт задолго до возникновения невосстановимой ошибки выполнит релок проблемного сектора.
В общем, не надо лишней паранойи, а то так и до шапочки из фольги дойти можно. В конце-концов, копия бэкапа на другой накопитель решит 100% возможных проблем с накопителем, а не 0.1%, которые решает добавление избыточной информации.
mistergrim
DrPass
Это тот самый UER. Но не суть важно. Как я выше дописал, если данные действительно важные, просто делайте две копии архива на разных накопителях. С накопителем может произойти всё, что угодно, и с вероятностью примерно 99.9% это будет отнюдь не то, от чего вам поможет примочка в виде добавления избыточности в архив.
mistergrim
У всех, советующих делать дополнительные копии, хотелось бы спросить — где вы деньги на дополнительные накопители берёте? Да, recovery record не панацея, и не замена бэкапа, но значительно лучше, чем ничего.
DrPass
Эм… а на календарь вы смотрели, когда я просил? 2021-й год, напомню. Четырехтерабайтный винт стоит $100. Потратьте как-нибудь то время, которые у вас уходит на возню с архивами/архиваторами, просто на приносящую деньги работу, и купите себе несколько таких. И я не ошибусь, если скажу, что четыре терабайта способны вместить весь контент, который вы там у себя можете нагенерировать, если это не куча видео и фото. Но видео и фото, к слову, это такие замечательные форматы, которые
а) не нуждаются в архивации
б) без особых проблем перенесут все те UER, если их не архивировать :)
совершенно незначительно, если точнее. В том-то и дело.
JerleShannara
Ответ простой: лента.
sumanai
Дорого.
JerleShannara
Если брать для себя новый и современный привод — да, если брать LTO5/6 б/у — нет.
sumanai
Ну как бы сказать… Посмотрел на авито, там от 20к и до 80-ти. Не сказать чтобы дёшево. Ну и надёжность подобного решения вызывает вопросы, приводы старые, и читать их скоро может стать негде.
DrPass
Да все равно дорого, к тому же возни много, по сравнению с обычными винтами.
sumanai
То есть на обычную информацию вам плевать, зато в архиве всё классно?
saboteur_kiev
Суть в том, что хочется поставить один архиватор. Вы выбрали winrar, другое человек выбрал 7zip. И этого достаточно, чтобы распаковать и тот и другой архив, если его вам прислали.
Но вот два архиватора ставить уже не нужно, и в этом — плюс.
DaemonGloom
Если бы при установке архиватора было окно "Выбрать 7-zip стандартным приложением для архивов?" — вопросов бы не было совсем. Показывать каждый раз — это перебор, разумеется.
mSnus
Мне кажется, гипотетической бабушке проще сделать клик с шифтом, чем искать в настройках нужную галочку: ассоциировать себя с 7z, со всеми архивами, выборочно с такими-то архивами… проще кликнуть)
drWhy
Настоящие_программисты_не_пользуются_пробелом. Бабушки_не_пользуются_шифтами. Обычно.Из любого правила, конечно, есть исключения, например «Бабуля КОБОЛ».
hottabxp
Если вы про интеграцию в проводник, значит вы установили 7-Zip 32-bit x86 на Windows x64.
drWhy
64/64, только что проверил.
Aquahawk
Запустите от администратора
drWhy
И я о том же. Запустить от администратора, и не факт что поможет, найти пункт в GUI и привязать оттуда, привязать вручную к нужным расширениям, смахнуть пыль с любимого бубна — всё это не про пользователей — у них либо «работает», либо наоборот. У WinRAR интеграция «работает», у 7-Zip пока не совсем. Это, на мой взгляд, причина, почему платный WinRAR всё ещё популярен.
kolodkin
Хз зачем нужна эта привязка. Обычно все ограничивается контекстным меню распаковать тут и всё.
drWhy
Не все пользователи владеют контекстным меню. Вы же запускете файл .docx почти наверняка не через выбор пункта «Открыть» или «Изменить» в контекстном меню, да и искать настройку привязки типов файлов в Word'е не приходится, файловые ассоциации регистрируются автоматически при установке.
Если уж работа с файлами в Windows построена на их типах и привязанных к ним стандартных открывалках, почему бы просто не сделать как все, особенно учитывая отсутствие в системе мало-мальски достаточного собственного архиватора. Иногда складывается впечатление, что Microsoft состоит в негласном сговоре с разработчиками системного и прикладного ПО и именно по этой причине в системе за тридцать лет отсутствуют или находятся в зачаточном состоянии некоторые элементарно необходимые вещи.
DirectoriX
Как все (в наши дни) — это весьма вероятно Electron-приложение, которое устанавливается в AppData, зачастую даже без возможности выбора.
Строго говоря, ОС должна уметь только загрузиться и дать возможность пользователю что-то запустить. ОС не обязана быть комбайном, который готов для любой вообразимой задачи, она должна быть достаточно компактной. В противном случае получим новый виток «Объёмных объектов» (3D — это же круто!), OneDrive, который нельзя удалить просто так (но ведь все пользователи хотят в облако фотографии котиков складывать!), возможность удалить «Калькулятор» (пф, у каждого смартфон в кармане, зачем им на компе считать?), но не «Карты» (а вдруг тот самый смартфон разрядится, а про сайты человек не в курсе) и так далее. Нет уж, давайте ОС будет давать в первую очередь возможности, а не решения.
drWhy
Выше уже предлагал такой умозрительный приём — берём гипотетическую бабушку, получившую от внучика архив 7z. Вам досталась почётная задача объяснить бабушке, как архив открыть. Вы всего за полчаса сумели пошагово провести бабушку через процедуру скачивания и установки нужного ПО. Теперь остались мелочи — собственно распаковать архив и убедиться, что следующий архив также успешно распакуется.
DirectoriX
Если бабушка за полчаса смогла найти (под руководством) оф.сайт, скачать и установить программу, то двойной клик на неизвестном (пока что) *.7z файле — выбрать 7zip и просто не снимать галочку «Всегда использовать это приложение для открытия .7z файлов» она освоит ещё минут за 5-7.
drWhy
Возможно, но зачем?
DirectoriX
Хорошо, ответный вопрос: а зачем внучок ей отправлял 7zip архив, если не уверен, что бабушка сможет его открыть? Почему не *tar.gz сразу, пусть помучается с двухступенчатой распаковкой?
Вроде как все околоайтишные люди знают, что если не уверен, есть ли у той стороны нужное ПО — отправляй в максимально распространённом/примитивном формате.
drWhy
Потому что внучик продвинутый, а в архиве несколько сотен файлов — их отправить поодиночке будет несколько сложнее.
DirectoriX
DrPass
Продвинутый бы выложил фоточки в гуглофотках, и отправил бы бабуле ссылку. А это какой-то извращенец. Может, он ей вообще не внучок, а обхаживает, чтобы квартиру переписала?
drWhy
Ну вот почти что случай из жизни — присылают не ссылку на гуглофотки со свадьбой, а избранные фото, чтобы восприимчивую бабулю не доконать современностью мероприятия.
DrPass
По-моему, скопировать избранные фото в другой альбом гуглофоток — это даже проще, чем сделать архив и отправить его бабуле.
drWhy
Мы вроде бы обсуждали недостаточную (на мой взгляд) интегрированность 7-zip, а не гуглфото. 7-zip появился в 1999 году, гуглфото — в 2015.
DirectoriX
Интеграция 7zip в Windows есть, причём даже лучше встроенного в Windows архиватора Zip. А то, что для этого надо сделать примерно 5 кликов мыши — совсем незначительный минус. Да, неприятно, но зато не будет, например, так, что VHD и ISO файлы стали открываться в 7zip, а не VmWare и каким-нибудь Daemon Tools соответственно.
DrPass
Гуглофото тут приводится в контексте «ну и фиг с ней, с интеграцией, в 2021м-то году».
Опытный пользователь, если надо, быстро настроит. Неопытный, вроде упомянутой бабушки, никогда в жизни с тем 7-zip и не столкнётся.
drWhy
В итоге отличный бесплатный продукт с двадцатилетней историей не становится единственно необходимым в классе из-за мелкой особенности.
DrPass
Я вообще не знаю, что такое «единственно необходимый» в отношении архиваторов в 2021-м году. Мне бы, например, не пришло в голову что-то сжимать в формате 7-zip сейчас, равно как и rar, например. Я сделаю обычный zip-архив стандартными средствами ОС или файлового менеджера, и я буду знать, что тот, кому я отправляю архив, его сможет открыть без какого-либо дополнительного софта.
nero211
Вы пытаетесь натянуть сову на глобус. Всегда есть Anydesk\TeamViewer.
drWhy
Конечно есть. Ещё полчаса — и программа удалённого управления скачана и запущена.
И главное — если бы исходно программа привязалась с целевым файлам, удалённое управление не понадобилось бы.
DirectoriX
dzok
Этот вопрос вменяемыми внучками решается в момент приобретения пк бабушке. Самые вменяемые еще и не форточки бабушке оставят, ибо пк для некомпетентных должен быть неубиваем априори и включаться/выключаться одной кнопкой как любой электроприбор.
kolodkin
Пример притянут за уши. Если вы знаете что получатель плохо умеет работать на компе, то вряд ли вы будете усложнять ему жизни запаковывая файлы в 7zip архив. А уж если это ваша бабушка то проще иметь удалённый доступ и самому положить все куда надо. Опять же можно сделать sfx архив.
Lennonenko
я расскажу, как запустить anydesk и сделаю всё сам точными отработанными движениями
kocherman
Zip встроен в Windows не помню точно когда, но в Windows 95 уже был. Да, там не было криптографии, но сжать папку в один файл можно было. И, кстати, при установке WinRar этот пункт меню автоматически пропадает, и на месте него остается привычный многим пункт меню с тремя книгами на иконке. Начиная с Windows 98 можно пользоваться документами в zip-архиве не распаковывая архив полностью.
А вот прописывание дефолтных обработчиков на общепринятые форматы файлов меня вымораживает. Я как-то лет 5 назад из-за этого выпилил очень хорошую программу Audacious из репозитория сборки, которой пользуются каждый день очень много человек. Этот Audacious прописал себя открывать по дефолту на mime-тип
inode/directory
. Ох сколько было мата…Так то, разработчики Audacious наверняка думали, что это удобно загружать в музыкальный плеер всю папку целиком и потом рекурсивно найти аудиофайлы всех форматов. Но они упустили момент, что папки бывают не только с музыкой, а еще и с документами и вообще со всякими файлами. И видя как открываться аудиоплеер, когда тыкаешь по папке — это как-то сбивает с толку.
storoj
в win95 как-то рановато, минимум в win2000, и то не факт
DrPass
Если точнее, то в Win 98 она появилась, только не в стоковой, а с пакетом расширения Windows 98 Plus.
salnicoff
Нет. Встроенный в Проводник архиватор появился в Windows XP.
VEG
В Windows Me уже была встроена поддержка ZIP. В Windows 98 доустанавливалось вместе с официальным Windows 98 Plus.
salnicoff
В ME вроде только распаковка была. А ставить Plus — это уже лишние телодвижения, с таким же успехом можно было и WinZIP поставить.
drWhy
«Да, там не было криптографии, но сжать папку в один файл можно было.»
Там нет ничего из расширенной функциональности — разбиения на тома по размеру, управления степенью сжатия, сохранения/восстановления даты/времени, и много чего ещё.
Как и во многих других случаях, IMAPI например, складывается впечатление, что у МС есть отличные программисты, умеющие реализовать полноценно функциональность, доступную в сторонних продуктах, развивающихся на протяжении десятилетий, но при интеграции в ОС большая часть уже реализованной функциональности остаётся недоступной из-за криворукой реализации соответствующего GUI. При этом недостающая функциональность может быть вполне доступна из командной строки или хитровыделанного API, но это совершенно бесполезно для большинства пользователей.
DirectoriX
Ну знаете, в Windows и полноценного текстового редактора нет предустановленного (только WordPad, а может и его выпилили), а уж он-то чаще нужен пользователям, чем «разбиение архива на тома по размеру, управление степенью сжатия, сохранение/восстановление даты/времени, и много чего ещё». А «Блокнот» даже номера строк не показывает слева, не говоря о подсветке синтаксиса (в отличие от какого-нибудь gedit из линукс-мира).
drWhy
Это другое. К примеру, у Вас есть дискета и флешка с малым свободным объёмом, и нужно перенести на другой компьютер, не подключённый к сети, данные. Есть даже встроенный архиватор, но как ему объяснить лимит на размер архива? Вручную подбирать файлы и сжимать по частям непродуктивно, т.к. степень сжатия сильно варьируется в зависимости от характера файла. В итоге либо придётся очищать флешку, либо искать другой архиватор, то и другое требует лишних телодвижений, в любом случае встроенный архиватор становится бесполезным. Пример может быть и несколько устаревший, но и проблеме уже не первый десяток лет.
kocherman
Вы про добавление CRC-суммы к каждому блоку данных, чтобы можно было идентифицировать испорченные блоки не теряя архив целиком? Так это, вроде как, в формате 7z встроено by-design.
mk2
Надо полагать, хочется как в winrar, чтобы можно было исправить испорченные блоки.
kocherman
Как? Ок, я добавлю в архив 5% избыточных блоков и поменяю 50 рандомных байтов равномерно во всем архиве. Как он сможет по 5% восстановить 100% данных?
M_AJ
С помощью силы математики конечно :) В комментах долго рассказывать, но в сети много информации на эту тему вот например статья на Хабре
saboteur_kiev
если 5% это больше чем 50 рандомных байт, то так и сможет. Вы бы документацию почитали.
darkdaskin
В WinRAR есть возможность разбить архив на N частей, из которых любых M достаточно для распаковки (либо не разбивать архив, а просто добавить в файл избыточных блоков). 7-zip из коробки так не умеет, но можно создать файлы с информацией для восстановления с помощью MultiPAR.
sumanai
Автор знатный наркоман.
drWhy
Именно про добавление избыточной информации.
Однажды, довольно давно, по моей вине очередной раз была задержана научная работа — сжал архиватором небольшую папку с исходниками проекта вместе с большим файлом экспериментальных данных с установки и впервые не протестировал архив — очень торопились. Как выяснилось позже, файл данных можно было легко получить снова, а исходники не распаковались из-за единственного сбойного сектора на hdd. Автор исходников стоически отнёсся с происшествию, сообщил, что работа уже сгорала в пожаре и однажды была украдена из лаборатории вместе с компьютером.
С тех пор предпочитаю добавлять информацию для восстановления в архив с важными данными. Потеря нескольких процентов объёма с лихвой компенсируется увеличением стойкости архива к повреждениям, превышающем обычную проверку CRC.
DirectoriX
Люди делятся на три типа, кто не делает бекапы, кто делает бекапы, и кто уже делает бекапы. Вы из первого типа в третий не перешли, увы.
Жёсткий диск очень любит сыпаться последовательными блоками, так что «нескольких процентов» мало, надо или приличные 15-20, или просто сделать копию на другой носитель.saboteur_kiev
Плохо помните классику.
Те, кто не делает бэкапы
Те, кто уже делает
Те, кто уже делает и проверяет их целостность.
DirectoriX
Видимо, у нас разные источники :)
vriska
Спасибо пользователям Windows за бета-тест ^^
drWhy
Пожалуйста.
NikitOS9
peazip
singular_asm
Поддерживаю. Peazip — швейцарский нож. Столько параметров нет ни в одном другом GUI архиваторе. 7-ZIP и рядом не стоит.
saboteur_kiev
он даже winrar переплюнул?
DrPass
А сколько из них нужных параметров?
Ulrih
Интересно зачем? Это как портированные фар когда есть мц
drWhy
Джаст вай нот? Они похожи только внешне. Да и MC вроде бы не особо развивается, а у Far куча плагинов.
rionnagel
mc 4.8.26 (10 января 2021)
У mc внутри куча интеграций и кастомных настроек.
Кто привык — тот и будет юзать FAR. Лично мне он отвратителен.
drWhy
Они почти ровесники. Пользуюсь Far'ом почти четверть века, пока отвращения не вызывает, правда на Windows. Пользовался MC без отвращения, но и без желания заново вникать в тонкости. Благо Far всё-таки портировали, как и MC, так что у всех есть возможность использования предпочитаемого инструмента.
rionnagel
Я с вами согласен. Но мне ближе даже нортон и волков коммандеры.
Тут кто к чему привык). Кто-то пользуется и тем и тем, кто-то совсем другим.
Понимаете, продукты делают ± одно и то же. Но когда ты привык к логике действий и шоткатов mc и пробуете тот же фар, то начинается попаболь из-за того, всё делается по другому, другие шоткаты, другие плагины и интеграции. Ровно, как и наоборот.
ps. лол, мне за 5+ лет комментирования на ресурсе каждый раз минусят карму за комменты про FAR). Кто-то видимо очень ярый фанат.
drWhy
Забавно, когда это происходит молча.
icCE
так и far завезли уже в linux
drWhy
Именно, и есть кому сказать спасибо.
saboteur_kiev
far под линукс и под windows (+conemu) — довольно разные вещи…
rehci
Архиваторы сейчас как программы для записывания CD — в основном утратили свою основную функцию. Пользователи их используют, в основном, просто чтобы получить один файл, вместо рассыпухи и куда-то его переслать. Соответственно лучше тот, который быстрей, т.к. проще скачать в полтора-два раза больше, чем ждать пока оно распакуется.
kompilainenn2
Не правда. Рассыпуха рассыпухой, но и сжать всю эту рассыпуху тоже полезно. Даже 30% экономии места и траффика — это прилично
rehci
Может вы имеете ввиду системное, сетевое применение? Я специально упомянул "пользователей". Действительно массивный контент (фото, видео) и так сжат по максимуму. А мелочь? Какая разницу сколько она там весит.
drWhy
Архив из тысячи мелких файлов скопируется на флешку гораздо быстрее, чем папка с распакованными файлами.
staticmain
Сейчас к вам прибегут свидетели сетевых хранилищ и расскажут, что флешкой они пользовались в последний раз в 2010м.
drWhy
Как говаривал знакомый — лучшая флешка это карандаш. Облака тоже горят, про вчерашний пожар в датацентре, кажется, уже три статьи.
В облако архив упорхнёт тоже быстрее, чем папка.
KvanTTT
Лучшая флешка — это диверсификация хранилищ.
F0iL
Так в сетевые хранилища цельные архивы зачастую тоже быстрее копируются, по сравнению с рассыпухой из сотен файлов :)
JerleShannara
Мне проще распаковать 40+ гигабайт в 200, чем эти 200 скачать.
nixtonixto
Архиваторы позволяют зашифровать пересылаемый файл.
FFiX
Это не их основная функция. Для шифрования всегда есть gpg, openssl и прочие утилиты.
И тот же tar, например, не умеет ничего шифровать сам.
nixtonixto
Ну, попробуйте объяснить слабой в компьютерах и инглише китаянке, как ей быть с присланной документацией, зашифрованной с помощью перечисленных вами утилит. Вместо даблклика по файлу и ввода пароля в окошке. Поэтому уверен, что большинство пользователей для шифрования использует именно архиватор.
13werwolf13
если эта гипотетическая китаянка не умеет читать то какого простите ляда она сидит за компухтером?
а так файл зашифрованный тем же gpg по даблклику в винде предлагается рассшифроваться клеопатрой при наличии оной. удобство одинаковое.
здесь вы скажете что архиватор у неё в 99% случаев уже стоит а win gpg пакет нет… ну так это вопрос популярности а не удобства. и уж точно не имеет отношения к гипотетической китаянке
VEG
Решение где это всё интегрировано просто удобнее. Например, вам не нужно расшифровывать и разжимать весь поток данных, чтобы посмотреть какие файлы там хранятся. Вы можете опционально зашифровать имена файлов, или оставить их в нерасшифрованном виде, что тоже бывает удобно. Сжатие также работает лучше в 7-zip, так как он для разных типов файлов в архиве умеет автоматически применять различные фильтры для повышения степени сжатия. Если архивировать всё в tar, а потом запаковывать в xz, то сжатие может оказаться значительно хуже, чем если бы всё архивиловалось и сжималось в 7z.
13werwolf13
опять же вопрос насколько хорошо сжалось это одно и я с этим не спорю. удобство это другое
я про удобство
гуёвый ark создаёт из папки архив одним кликом. и юзверю знать не надо чем отличается .7z от .tgz (.tar.gz)
главное чтобы админ заморочился и поставил необходимый набор софта. за что кстати я в винде и любил 7-zip. он открывал любые архивы и не только архивы
VEG
Вы не поняли. Не интегрированное решение, а такой «бутерброд», будут делать много лишней работы. Нельзя посмотреть список файлов без расшифровки и распаковки всего потока. Невозможно сделать запароленный архив с видимым списком файлов. Одно специализированное решение, которое совмещает в себе все нужные функции, может позволить себе быть более гибким в этих вопросах.
Это как новый протокол QUIC (поверх которого работает новый HTTP3). Он совмещает в себе функции TCP, TLS, плюс мультиплексирование потоков в стиле HTTP2. И это даёт ему множество преимуществ по сравнению со старым решением, где надёжная доставка, шифрование и мультиплексирование делалось отдельными технологиями.
sumanai
Эм, я вижу такое же количество слоёв. Только QUIC стал жирнее, чтобы монополия гугла над интернетом лучше просматривалась.
VEG
Разработкой QUIC занимается целый ряд заинтересованных организаций под флагом IETF. Google только предложил первую версию в 2013 году. С тех пор разрабатывается всеми заинтересованными компаниями, и сильно отличается от того, что предлагал Google. И нет, у Google там не большинство голосов. Только 8 лет спустя все пришли к какому-то консенсусу и основная часть стандарта уже почти закончена (но продолжается работа по расширениям типа пересылки UDP-подобных пакетов через QUIC-соедиение).
Визуально кажется что уровней столько же, но UDP там используется только для совместимости с существующими сетями, потому что только так сегодня можно добавить новый протокол транспортного уровня без замены всего железа по всему миру (что близко к невозможному). То есть его роль только в совместимости с существующими сетями. Сам по себе QUIC несёт себе функции TCP, UDP, TLS и мультиплексирования нескольких потоков через одно соединение (что ранее было частью HTTP/2), с кучей новых классных возможностей. То есть раньше часть задач транспортного уровня был вынужден брать на себя HTTP/2 (мультиплексирование нескольких потоков), что было не очень логично, и оно работало плохо из-за всей этой матрёшки (потеряли один пакет одного потока — застряли сразу все потоки), сейчас это ушло куда и положено, на новый транспортный протокол в лице QUIC (который ещё и заменяет TLS, так как только при такой интеграции можно избавиться от недостатков старой связки TCP+TLS+мультиплексор потоков).
makkarpov
Ну, теоретически можно было бы взять стек UDP/DTLS/SCTP/протокол приложения сверху.
DTLS шифрует пакеты SCTP, SCTP мультиплексирует потоки и обеспечивает надежную доставку (не страдая при этом проблемами TCP, когда один пропавший пакет тормозит всю очередь). Или не обеспечивает, если конкретно этому потоку такая доставка не нужна и он прекрасно живет с потерями. Или обеспечивает со стратегией "если за секунду пакет не ушел — выкидываем". Там много настроек.
Приложение работает уже поверх SCTP с абстракцией "много надежных зашифрованных потоков". Но у этого стека есть фатальный недостаток.
VEG
Можно было, но у SCTP+UDP были некоторые недостатки, которые в том числе хотелось решить. QUIC быстрее устанавливает защищённое соединение, и он умеет в миграцию соединения если клиент перемещается из сети в сеть (был на мобильном интернете, стал через Wi-Fi и т.д.), наверняка и какие-то другие преимущества есть. Вы посмотрите сколько реализаций QUIC в разработке. Протокол интересен далеко не только одной Google. Это совместное усилие, потому что преимущества того что предложил Google 8 лет назад были очевидны всем, поэтому идею и подхватили и начали развивать вместе. И это прекрасно, так как это как бы повышает шансы, что стандарт пишется не в стол, а будет на самом деле применяться.
Синдром NIH — это когда какая-нибудь Apple делает свой изначально проприетарный ALAC, который совершенно непонятно зачем вообще создавался, потому что он буквально во всём хуже FLAC, который был создан раньше и был изначально свободным.
А если есть возможность предложить что-то лучшее, чем уже существует, то это уже не NIH, а развитие технологий. Если при этом компания кооперируется с другими заинтересованными сторонами для того, чтобы получить ещё более продуманный стандарт — это ещё лучше.
makkarpov
Тут больше претензия в том, что на выходе вместо модульных частей получается монолит, который хорош только в том, подо что его затачивали.
Да, разумеется, слоистое решение не идеал в плане эффективности. После DTLS можно не делать SCTP-хендшейк, например, а сразу инициализировать протокол каким-то состоянием. Насчет миграции, кстати, не согласен. DTLS в такое должен уметь, если правильно написать UDP-слой. Но это можно дорабатывать, сохраняя модульность. Заодно и реализации этих протоколов нормальные появятся, а не, упаси господи, usrsctp. Еще я с некоторым подозрением смотрю на попытку переизобрести TLS. Понятно, что там учтен опыт нахождения дырок в оном, но все же.
А пока, как я понял, на выходе получается вишмастер, который можно воткнуть, если приложению нужно мультипоточное надежное соединение. А если нужно чуть другое — уже нельзя.
kocherman
Индекс-файл может создать и tar. Просто это указывается отдельным параметром.
ZyXI
И результат будет отдельным файлом, при этом решающим только задачу «получить список файлов в архиве без распаковки». Смещения начала файлов в нём не указаны, так что достать один файл он вам не поможет, даже если вы используете несжатый архив. Во всяком случае, именно так выглядит результат создания index-файла с помощью
--index-file
.Вообще некоторой доработкой формата можно было бы добиться нужного эффекта: просто научите tar дописывать этот index-файл в конец архива (для совместимости: не в виде файла, а просто в виде некорректных данных после конца архива) и передавать xz параметр
--block-list
с такими значениями, чтобы один файл соответствовал одному блоку. Но это мало кому нужно, и вызывает необходимость что-то делать с разными особыми случаями вроде «что делать, если файл обрезали после того, как tar передал--block-list
но до того, как он начал запаковывать файл» (вопрос, в принципе, решаемый, если вы засунетеxz
внутрь tar или сделаете так, чтобыxz
принимал на вход поток команд, а не просто поток данных).nixtonixto
На вкус все фломастеры одинаковые, не хочу спорить ради спора, но сложилось так, что винрар, офис, адобридер стоят на 99% компьютеров, поэтому файлы в этих форматах у 99% не вызовут затруднений. Поэтому шифровать для себя можно хоть трукриптом в контейнер, а если планируется передавать файлы, то — архиватором…
sumanai
Винрар платный как бы.
kocherman
А офис и акробат бесплатные?
VEG
Есть бесплатные LibreOffice и SumatraPDF =)
vindy123
Рулю службой поддержки пользователей и с лютой завистью смотрю на таких счастливых обитателей мира единорогов и радуг, как вы :) без обид, но 95% пользователей ПК независимо от национальности просто не поймут, что вы им предлагаете. А мне не нужно нести просвещение в массы, мне нужно убедиться, что проблема клиента решена наиболее простым и быстрым способом. Если бы я каждый раз заворачиваться в белый плащ и орал "ты дура тупая" на каждую китаянку — я бы давно свой выдающийся ум демонстрировал не коллегам, а другим нищим бездомным бомжам на привокзальной площади.
dartraiden
Вот да. Мои бэкапы лежат в зашифрованных 7z-архивах (причем, жмутся выборочно, например, образы виртуалок ради экономии времени лежат в архиве без сжатия, а документы лежат в другом архиве и сжаты). Мне банально удобно, что я могу двойным кликом открыть бэкап, ввести пароль, и вытащить, например, какой-то один файл, и для этого не нужны никакие клеопатры, всё делает одна утилита.
И, вроде, я не тупая китаянка, но в упор не понимаю, зачем бы мне устанавливать и использовать сразу несколько утилит, если от этого я не получу ровным счётом никакого удобства или выигрыша.
Phemto
Запись на CD активно используется в медицине, те же томограммы. Если писать на «свисток», то через какое время инфа улетит? А так CD можно в конвертике хранить годами. Так же и с архиваторами.
sumanai
Мой CD с МРТ зубов кажется так никто и не открыл. Ссылку на облако кинули мне на почту и в клинику ))
drWhy
Скорее КЛКТ.
DrPass
Если бы ещё и приводы CD годами хранились…
grayich
Вот чем реально 7zip хорош, что у него с рождения не было проблем с кодировками на любых OS.
Sap_ru
Зато доавбить сохранение базовых прав, ссылок и прочего они не могут. Как можно было сноля сделать архиватор и не заложить в него ссылки, специальные типа файлов и сохранение прав?!
FFiX
С учётом появившейся только в 20й версии поддержки Linux и отсутствием поддержки macOS не вижу ничего странного. В виндовых архиваторах такого почти нигде нет.
Sap_ru
Билды под линукс уже давно были и 7z есть во всех репах. Реквесты добавить сохранение метаинформации ещё 10 лет делали. Самое главное, что там делов-то всего ничего и уже была пара пересмотров формата файлов. Была бы метаинформация, проект бы гораздо веселее развивался — был бы смысл подключаться другим разработчикам. А так на всё вопросы автор 10 лет отвечает, — «я ничего в этом не понимаю, этого не будет», — что круто всех обламывает.
FFiX
Под Linux и macOS есть p7zip. Это отдельная утилита, разработка которой приостановилась лет 5 назад (но в некоторых дистрибутивах уже перешли на его форк).
В остальном — да, всё так.
С другой стороны, а зачем в Linux нужен именно 7z? Есть же xz-utils, использующий те же алгоритмы сжатия (LZMA/LZMA2). В комбинации с tar он решает задачи сжатия и архивации данных.
Sap_ru
1) Сделайте листинг большого xz-архива на десяток гигабайт. Особенно в каком-нибудь файловом менеджере.
2) Распакуйте 1 небольшой файл из 32 GB архива xz.
3) Сделайте инкрементальный архивы, дельта архивы, обновление содержимого архивов и т.п. под xz.
4) У вас Linux, но вам нужно передавать архивы и работать с ними под Windows.
6) Вы хотите гибко управлять компрессией.
7) Вам нужно user-friendly шифрование, чтобы самый тупой сотрудник потом можно это расшифровать под любой OS.
8) У вас Windows, но вам нужно получать архивы из Linux.
9) У ваших заказчиков Windows и вам нужен какой-то user-friendly архиватор для взаимодействия с ними.
10) Вы хотите удобно и кроссплатформенно работать с zip-архивами.
11) Вы хотите удобно распаковывать JAR, RAR, CAB и тому подобное.
12) Для вашего проекта нужна серьёзная работа с архивами из собственной программы.
7zip на голову лучше вообще всего и по всем параметрам. Единственный минус — отсутствие поддержки сохранения метаинформации POSIX.
fshp
Замените xz на pixz. Он индексирует tar при сжатии и сжимает блоками для быстрой частичной распаковки.
Sap_ru
И как мне из файлового коммандера или из винды листинг архива просмотреть? Вы же в курсе, что он в своём формате это к архиву добавляет?
fshp
А 7zip не в своем формате сохраняет?
Из консольки можно посмотреть. Или поискать/написать плагин для mc/total commander. Благо для mc дальше баша лезть не придется.
Замечание было лишь по первому пункту. Если вам часто нужен листинг, то используйте форматы с индексом.
Если вы не сами архивы создаёте, а получаете извне, то у вас и выбора то нет. Что прислали с тем и работаем.
Sap_ru
И какой именно кросплатформенный архиватор с индексом, поддержкой многопоточности и шифрования мне нужно использовать? ;)))
fshp
Ну я же не призываю вас отказаться от 7zip. Мы тут рассматриваем возможные сценарии использования. Где-то 7zip хорош, где-то просто не имеет нужных функций.
Например вам нужно публичным ключём зашифровать архив.
Или подписать его.
7zip умеете?
saboteur_kiev
Там на самом деле достаточно было бы хранить только executable биты и все…
InterceptorTSK
архив без отказоустойчивости бессмысленнен по определению
ну да, вы скажете давайте сделаем ещё копию архива и пусть оно будет децентрализовано
так и это плохо, ибо тогда архив нужно бить на части или если архив повреждён, то что же это тащить весь по новой или всё же дотащить битую часть?
и т.д. и т.п.
на календаре наминутачьку 2021 и этот ваш севензип не может ничего логически актуально действительно нужного
извините, но… нет
п.с.: да, я за рар и ничего более функционального пока не придумали
sumanai
Отказоустойчивость сейчас реализуется другими средствами. Ну и 10 лет назад я паковал в RAR с 5% для восстановления, ни разу не понадобилось. Файл или целиком пропадал вместе с носителем, или жив-здоров и лежит на диске.
VEG
Проблемы с битыми архивами остались где-то в 90-х и нулевых, вместе с дискетами и оптическими дисками. То есть то что вы описываете к 2021 году лишь стало менее актуальным. А вот полноценный бэкап не утратил актуальность: риск полного отказа HDD или SSD хоть и мал, но всегда есть. Но это делается другими средствами.
Соглашусь, что как опция такая функция не помешала бы. Но на мой взгляд свободность 7-zip перевешивает это преимущество RAR.
mistergrim
Флэшки — крайне ненадёжный носитель.
Сеть — до сих пор порой есть вероятность скачать битый архив (а не у всех безлимитный гигабит, чтобы перекачивать, знаете ли).
Даже у HDD далеко не нулевая вероятность ошибки чтения/записи, а остаётся она на том же уровне, а объёмы-то растут.
nixtonixto
А для чего это надо 80% пользователей?
Sap_ru
А чем вы файлики архивировать будете? Zip? Так он плохо архивирует, медленно и криво. Rar, прости Господи? Так он денег стоит.
7zip это сейчас единственный нормальный бесплатный опенсорс архиватор.
nixtonixto
Я спрашивал, для чего 80% пользователей «ссылки, специальные типа файлов и сохранение прав»? Правило Парето 80/20…
WINRAR всегда был неограниченно условно-бесплатным. Ну окошко, ну и что… Тем более, что лечится.
Sap_ru
Вы, когда заказчикам работу сдавать будете, то так и напишите в ТЗ и документации?
80% нужен удобный интерфейс и кроссплатформенность. Оставшимся — плюшки и свистелки. Сейчас эти два множества пересекаются только на 7zip.
saboteur_kiev
В СНГ отношение к условно-бесплатному такое, что спасибо Рошалу он сделал для СНГ это бесплатным по умолчанию.
Но зарубежом к этому относятся серьезнее, особенно если не дома. И закупить winrar для компании в 10к сотрудников внезапно совсем недешево.
nixtonixto
Не совсем так, в этом вина финансовой безграмотности разработчика. В нулевых Винрар (да и почти любое другое приложение) стоил 30 долларов и для людей было слишком дорого платить 20% зарплаты всего лишь за архиватор. До разработчиков только сейчас стало доходить, что лучше получить по доллару, но с каждого, чем поставить запредельный ценник, который оплатит доля процентов аудитории — игры в Стиме, приложения в Плэймаркете стоят от доллара, а Офис даёт плюшки в виде 6 ТБ и люди не столько покупают офис, сколько эти терабайты… Это как с налогами — ты увеличиваешь налоги, а поступления в бюджет внезапно уменьшаются… Если бы Винрар тогда стоил вменяемые 1...3 доллара, и был простой и удобный механизм оплаты без похода в банк, то даже школьники, наверное, честно покупали лицензию.
iDm1
Вовсе не только в СНГ. Сколько встречал западных пользователей WinRAR — все использовали его так же бесплатно. У них покупка WinRAR даже своего рода «мем».
sumanai
А потом проверка и штраф.
Vindex
Про те 80% и не говорим
VEG
Вроде как по крайней мере сохранение прав (те что устанвливаются chmod) работает. Только что специально проверил предоставленной бета-версией. Не знаю как оно в p7zip было.
Sap_ru
Интересно. Нужно погонят. Если ещё хотя бы ссылки будут работать, то это просто праздник какой-то.
VEG
Ссылки тоже проверил. Не сохраняются. Но непонятно как их сохранять, если они куда-то за пределы архива указывают. Только если все ссылки на какие-то файлы внутри архива, тогда понятно. Думаю, наверняка можно добавить такое расширение.
ZyXI
Символическая ссылка — это технически обычный файл, содержащий путь к тому файлу, на который он ссылается и имеющий атрибут, указывающий, что это символическая ссылка. Чтобы сохранять их вам нужно просто иметь возможность считывать и сохранять этот атрибут и читать содержимое файла-ссылки вместо содержимого того файла, куда она указывает. Замечу, что вас при этом вообще никак не интересует, куда указывает символическая ссылка.
Сохранения информации вида «этот файл имеет тот же inode, что и файл X за пределами архива» (т.е. сохранения «жёстких ссылок») от архиватора не ожидают и, наоборот, все сильно расстроятся, если архиватор будет это делать (поскольку это либо уязвимость, либо бесполезная информация, либо повреждение распакованного файла). Сохранять информацию вида «это тот же файл, что и файл Y в архиве» можно, распаковывать потом с использованием жёстких ссылок — тоже, но обычно никто не заморачивается, поскольку жёсткие ссылки используются сильно реже.
Sap_ru
Причём, для NTFS 7zip ссылки криво-косо в одной из версий даже сохранял.
justhabrauser
В чем новость-то? Что в линухе появился архиватор 7z с CLI?
man 7za — никак?
LostAlly
Некоторым программам лучше не развиваться интенсивно, иначе они превращаются в годзил.
Единственной функции которой мне нехватает в 7z так это что-то наподобие виртуального диска(не знаю как точно назвать), чтобы можно было запускать например инсталляторы не распаковывая все.
mk2
В Windows такое сделать практически никак. А на linux есть FUSE + loop mount.
VEG
Если вы о чём-то не знаете, это не значит, что этого нет. Для Windows есть куча аналогов FUSE. Первые результаты из Google:
1. github.com/billziss-gh/winfsp
2. github.com/dokan-dev/dokany
3. github.com/crossmeta/cxfuse
mk2
Да, неправильно выразился. На Windows нет официального или общепринятого способа — только различной степени пригодности проекты. И как правило там какой-нибудь драйвер. Для себя использовать что-то можно, а вот встраивать в приложение я бы поостерёгся.
Сами Microsoft пилят ProjFS, но там свои особенности.
DCNick3
Они как правило предполагают использование дополнительного драйвера и потому сильно усложняют установку. Но да, они есть…
UPD: Я буду обновлять комментарии
EvilFox
Удалено.
Надо обновлять комментарии прежде чем писать.Temtaime
А зачем инсталляторы прятать в архив? Они сами по себе обычно пожаты.
Особенно забавляет когда архив с инсталлятором весит больше инсталлятора.
VEG
Часто инсталляторы состоят из кучи файлов. Даже если инсталлятор одним файлом, к нему иногда хочется приложить readme.txt или ещё что-то. Ну и ещё вариант — в архиве может быть много разных инсталляторов =)
saboteur_kiev
winrar, например, сам по себе неплохой инсталлятор. И установить и шоткаты сделать и в реестр прописать можно.
sumanai
Не актуально, те 5 мегабайт для скачивания настоящего установщика из интернета смысла жать нет.
LostAlly
Инсталяторы, это пример, нам клиенты часто присылают макеты в архивах по несколько файлов, а то и десятков файлов. На самом деле довольно много сценариев, вплоть до редкоиспользуемой portable программы, которую держал бы в архие и раз в месяц запускал.
OnYourLips
Подскажите удобный формат архивов для бекапов:
saboteur_kiev
права относятся к файловой системе, а не к архиватору, симлинки тем более — это надо понимать где будет происходить распаковка, и подходит ли данная ОС под такие права.
Поэтому tar умеет максимум executable бит сохранить, а не права.
drWhy
Так сохранять можно было бы уметь всё, а восстанавливать при распаковке только доступное в текущей ОС/ФС.
fshp
tar умеет хранить права, uid, gid и даже acl.
saboteur_kiev
А как uid/gid сохранить между разными системами?
Вдобавок все равно, если распаковывать под рутом, то можно потом chmod, а если под юзером, то как он в принципе имеет право создавать файлы, принадлежащие другому uid?
Бессмысленная вещь.
Вдобавок gnu tar этого не умеет, а выяснять на каком отдельно взятом дистрибутиве чего, tar нестандартный…
andreymal
tar (проверял именно gnu) сохраняет не только uid/gid, но и строковые user/group, которые между системами уже весьма неплохо переносятся
saboteur_kiev
Можете показать ваш man tar об этом? Потому что как я вижу, gnu тар хранит только uid/gid
Просто при запаковке можно указать ему строковые имя пользователя, группы, но он их переведет в UID/GID текущей системы и сохранит именно числовые значения.
andreymal
Во-первых, зачем мне man, когда я тупо смотрю созданный tar-архив через hex-редактор и вижу, что там записаны пользователь и группа в виде строк? А когда я распаковываю tar на другой системе, они прекрасно мапятся на локальные uid/gid (которые иногда отличаются) — я это активно использую на практике, хотя в ман даже ни разу не заглядывал.
Во-вторых, ну а если вы хотите всё-таки ман — вот вам ман:
https://www.gnu.org/software/tar/manual/html_chapter/Formats.html#Attributes
saboteur_kiev
То есть распаковывать нужно только от рута?
andreymal
Во-первых, ну как бы да, а почему вы вообще ожидали, что tar каким-то волшебным образом обойдёт ядерные ограничения и сделает chown в обход штатных механизмов ограничения доступа?
Во-вторых, ну на самом деле если очень хочется, то можно — например, подключить какую-нибудь фейковую файловую систему (через FUSE например), которая не ограничивает chown, тогда tar успешно пропишет правильные uid/gid/user/group и без рута.
saboteur_kiev
в том-то и дело, что смысл в хранении uid/username не особо нужен.
andreymal
Ну почему же, для бэкапов. Когда распаковка от рута автоматически проставляет все нужные права (и даже acl) — это сильно облегчает жизнь при восстановлении из бэкапа.
Кроме того, в tar-архивах можно таскать целые образы ОС — в таком формате например Arch Linux ARM распространяется.
fshp
Это просто числа. Какому юзеру и группе они принадлежат на другой системе не имеет значения. Если у вас в системе nginx имеет uid 10, а в target системе 10 это cups, то распакованные файлы nginx будут принадлежать cups.
Или у вас вообще может не быть юзера с id 10.
В большинстве дистрибутивов (я не уверен, просто эмпирическое наблюдение) за такими известными юзерами зарезервированы одинаковые id.
saboteur_kiev
А если я юзер user1 (uid 1000) и пытаюсь распаковать такой тар файл, в котором файлы были от юзера cups (10), при распаковке файлы будут кому принадлежать?
Или это новый внезапный способ сделать chown без root прав?
fshp
Не, распаковку с такими правами нужно производить от рута. Иначе можно было бы от юзера распаковать файл с suid например.
tar от юзера владельцем всех файлов сделает юзера.
Все упирается в то, что chown требует рута, даже если вы свой файл кому-то отдать хотите.
DCNick3
Есть pixz, он примерно как tar (поддерживается та же метаинформация) и xz (хорошее сжатие), но при этом ещё делает это параллельно (а не в один поток) и индексирует архив.
fshp
tar + pixz
Sap_ru
А теперь распакуйте один файл из 10Г под виндовз из без pixz. Или просто просмотрите список файлов без pixz.
fshp
А теперь распакуйте 7zip архив без 7zip. Не понимаю проблемы.
DirectoriX
Собранный под Windows pixz я не нашёл за 5 минут поиска. Если его необходимо собирать из исходников — это сразу -99% потенциальных пользователей. Более того, я вообще впервые про него увидел в комментариях на этой странице, хотя десктопный Linux в том или ином объёме использую вот уже лет 8. Про bzip, gzip, xz, pigz слышал, а про pixz — нет.
7zip — первый же результат в поиске, к тому же он достаточно известный, чтоб свою страничку в Википедии иметь (тоже не самый надёжный источник, но от слабой паранойи от потенциально малварьно-рекламной ссылки в поиске поможет). И да, он уже собранный для Windows. Им просто удобнее воспользоваться.
fshp
Вы наверное веткой промахнулись и хотели мне ответить в другой. Потому что у автора комментария выше требование сохранять права, симлинки. Раз для бэкапов то еще и спец файлы пригодятся.
DirectoriX
Нет, не промахнулся. Я именно хотел объяснить, что распаковать 7zip архив на Windows гораздо проще, чем pixz, с учётом необходимости установки самого архиватора.
fshp
Причем тут простота, если он не решает поставленную задачу?
Тут задача стоит траншею выкопать, а вы предлагаете автомобиль вместо экскаватора, потому что автомобиль водить проще и найти легче.
DirectoriX
Вероятно, Sap_ru важно иметь возможность делать переносимые между платформами архивы, поэтому и была фраза «распакуйте один файл из 10Г под виндовз из без pixz» (ну нет pixz для Windows). 7zip вообще упомянули вы в ответе (что в рамках этой статьи нормально), но как будто его тоже нельзя на Windows открыть, в такой же мере, как и pixz. Это не так, на что я указал.
fshp
Как вы себе представляете переносимость прав между Windows и Linux?
DirectoriX
Например, zip, rar, tar, tar+gzip/bzip2/xz, 7zip можно создать в Linux, а распаковать в Windows. Да, POSIX-права не сохранятся, но хотя бы дерево каталогов распакуете. С pixz всё не так однозначно
fshp
Юзеру нужны права. Он ищет альтернативу tar и gz. 7zip тут неприменим никаким образом.
Какой толк от такого бэкапа, если после его накатки система умрет?
DirectoriX
Какой толк от такого бекапа, если его даже накатить не выйдет?
fshp
Я упоминания windows тут не вижу. Впрочем как и linux, но это хотя бы понятно из упоминания tar и прав.
fshp
pixz собирается на винде через msys2, достаточно стянуть PKGBUILD из арча и добавить префикс к пакетам. Просто никто собраный пакет не опубликовал в репозиторий msys.
Ну или WLS2 можно использовать.
Я уже потерял нить спора и куда-то не туда ушел.
Для обычного пользователя кроме 7zip ничего и не нужно. Для необычного пользователя выполнить make install не должно быть большой проблемой.
DirectoriX
fshp
https://github.com/msys2/MSYS2-packages/pull/2369
Ну теперь не придется собирать :-D
saboteur_kiev
уж лучше tar + pigz
fshp
pigz не содержит индекса
saboteur_kiev
зато обратно совместим с gzip
fshp
Но он не решает задачу быстрого листинга файлов, которая требуется комментатору.
VADemon
SquashFS. С любым сжатием на вкус. На Windows только пакуется относительно медленно (если много маленьких файлов, так под 400к).
wormball
О нет! Всё это время я пользовался пиратским 7зипом! Что же теперь делать?
splitfire
В p7zip дико раздражает одна вещь: нет опции выставлять текущее время для распаковываемых файлов. Очень сильно не хватает этого.
dartraiden
Ещё в 7-zip дико раздражает некорректная работа с некоторыми tar-архивами, отчего их невозможно распаковать корректно.
engine9
В mint интегрирован удобный и надёжный менеджер архивов, который открывает и сжимает в кучу форматов в т.ч. и 7z.
KvanTTT
А с версией под mac что?
Vilgelm
GUI к 7-zip под Linux тоже уже есть.
papilaz
Я как-то попробовал разные архиваторы и вышло, что надо юзать gzip. Что упаковал 15 лет назад, и сейчас хорошо достается на любые линуксы. А опыт взаимоотношений показал, что "отдавай zip и там справятся". Всегда помни, что стой стороны "домохозяйка" будет распаковывать. Так что лишние 7% сжатия отступают перед 93% популярности.
Однако 7zip я всегда использовал для себя. В частности, то что занимало место, но придержать ещё надо, а 7zip жмёт хорошо и быстро.
dartraiden
С другой стороны, если человеку на том конце очень нужно, то он установит архиватор. Например, я в облаке держу и шарю файлы. Для меня критичнее всего — занимаемое место (облако не резиновое), а если качающий не хочет установить / обновить свой архиватор, то он волен поискать другой источник (учитывая редкость контента — искать он будет долго и не факт, что найдёт).
EddyEm
Я уже столько лет пользуюсь p7zip, что удивлен, узнав, что это — неофициальная версия…
С другой стороны, именно архивы 7z делаю достаточно редко, чаще я p7zip использую, чтобы создать самый обычный zip, который отправляю вантузятникам (потому что стандартный tar.gz не все могут открыть, был удивлен, впервые узнав об этом лет 15 назад!).
А вот когда я вижу архив в RAR, то однозначно понимаю, что сделал его вантузятник, выходец из бывшего СССР (потому что этой проприетарщиной больше никто и не пользуется).
mistergrim
EddyEm
Не 1%, а уже целых 5%!
И не всем же быть дятлами, как оставшиеся 95% населения!!!
Я вообще вантузоидов считаю некомпетентными. А уж если они еще и не хотят дела с линуксом иметь вообще ни в коем случае, то ненормальными.
mistergrim
Вам бы на opennet.ru с таким уровнем аргументации.
SargeT
7-Zip — для наилучшего сжатия, UE — для чтения всего и вся.
beneton2003
Посмеялся от души от манеры повествования автора!
izogrow
Ну все, осталось дождаться официального notepad++ на линукс
MegaLite
Интересно когда он войдёт в состав хотя бы Debian testing…
TakashiNord
Хорошая новость. Еще один архиватор в Linux-е.
Лишь бы ушлые товарищи не пытались им архивировать бэкапы архивов — баз и огромных данных.Иначе, даже сгоревший датацентр не поможет.
Scrin
Но зачем юзерам Линукса ГУЙ? Это ж вроде фишка такая у них — «элитарность» с использованием «чёрного экрана консоли», в отличие от нас, мастдаеводов.
P.S: ох, чую подгорит и минусов соберу.
sumanai
Интересно, на что вы рассчитывали.