The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В рамках проекта TheUnarchiver решены проблемы с использован..., opennews (?), 12-Май-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


63. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +1 +/
Сообщение от StrangeAttractor (ok), 13-Май-11, 01:11 
При всём уважении к RAR и его автору, очень плохо понимаю зачем сегодня (да, когдато он был лучим архиватором и почти не имел конкурентов) нужен RAR когда есть 7zip. Единственная известная мне фича WinRAR-а, которой нехватает в 7z - это возможность выборочной компрессии добавляемых в архив файлов по маске (чтобы при сжатии большой директории не тратить время пытаясь жать mp3 и т.п., а добавлять их в архив как есть).

А если бы ещё форматы bz2/gz расширили возможностью включения оглавления лежащего внутри tar-а чтобы можно было читать оглавление не разжимая архива (да, это автоматизировано, но разжатие-то всё равно всегда делается, что требует временм и места) - вообщн была бы красота...

Ответить | Правка | Наверх | Cообщить модератору

64. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +/
Сообщение от Иван Иванович Иванов (?), 13-Май-11, 01:19 
1) MM compression (WinRAR beats 7z at compressing WAV files).

2) Recovery records and volumes.

3) Much better UI.

4) Ubiquity.

Ответить | Правка | Наверх | Cообщить модератору

67. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +2 +/
Сообщение от StrangeAttractor (ok), 13-Май-11, 01:38 
> 1) MM compression (WinRAR beats 7z at compressing WAV files).

Pretty rare application, IMHO. I believe the percent of users needing to use and archive wav files regularly is relatively small (even among jsut RAR users).

> 2) Recovery records and volumes.

Can you explain why aren't recovery records completely useless today and why are not volumes close to useless today too? IMHO these features were only useful during the age of floppy diskettes and analog modem BBSs.

> 3) Much better UI.

Slightly better, if you dont think of fancy icons to be a feature of the most importance.

> 4) Ubiquity.

Legacy.

Ответить | Правка | Наверх | Cообщить модератору

84. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +/
Сообщение от Иван Иванович Иванов (?), 13-Май-11, 14:32 
> Can you explain why aren't recovery records completely useless today and why are not volumes close to useless today too? IMHO these features were only useful during the age of floppy diskettes and analog modem BBSs.

It looks like your computers experience is quite limited - I've seen many times files being broken on transfer from the Internet, or when copying *withing one* HDD, or copying to a faulty USB stick, or through broken USB controller/cables.

As for local storage only ZFS protects from such errors, but still it cannot *recover* from errors.

All my RAR archives are protected with RR, and I've never regretted this decision.

Ответить | Правка | Наверх | Cообщить модератору

87. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +1 +/
Сообщение от StrangeAttractor (ok), 13-Май-11, 15:39 
>> Can you explain why aren't recovery records completely useless today
> It you looks like your computers experience is quite limited

Perhaps that's why I do bother asking you to explain? ;-)

I've been using rar from the time of 5.25. diskettes. I used to be an RR fan too (believe me or not, I've once said that I can hardly understand why don't everyone use RAR -  the same thing I am saying about 7zip now). But practically it has only helped me once. Once during 15 years. And that was a broken diskette.

> I've seen many times files being broken on transfer from the Internet

The last time I've experienced this was the year 1999 when I was using dial-up Internet connection on Windows 98. I don't mean it can't happen today at all, I just mean this is very improbable...

> As for local storage only ZFS protects from such errors, but still it cannot *recover* from errors.

AFAIK there are many more file storage redundancy solutions.

Ответить | Правка | Наверх | Cообщить модератору

86. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +/
Сообщение от Ананимуз (?), 13-Май-11, 14:53 
> 3) Much better UI.

Так уж и better? Рюшечки и навороты, это не всегда хорошо.
Многим моим подопечным наоборот нравится простой интерфейс в котором негде заблудится.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

99. "В рамках проекта TheUnarchiver решены проблемы с..."  +/
Сообщение от anonymous (??), 13-Май-11, 23:33 
> 1) MM compression (WinRAR beats 7z at compressing WAV files).

а flac beats WinRAR для WAV files. и что?

> 3) Much better UI.

спорный вопрос.

> 4) Ubiquity.

не менее спорный.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

108. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +/
Сообщение от Аноним (-), 14-Май-11, 17:18 
> 1) MM compression (WinRAR beats 7z at compressing WAV files).

Все-равно FLAC лучше. Он и хорошо жмет и играется с распаковкой на лету. Сжатие вавок интересно как абстрактный писькомер для ностальгирующих по доFLACовым временам некроманов.

> 2) Recovery records and volumes.

7zip тоже умеет тома. Recovery records - вот хз, но если реально надо то коды коррекции ошибок донавешиваются внешними программами. При том, зная ожидаемый тип ошибок, можно подобрать наиболее подходящий код. А не так что 1 алгоритм на все случаи жизни, поэтому в половине случаев он сливается.

> 3) Much better UI.

Виндозные гуи примерно одинаковы. Отличие? Ах, ну да, в винраре иконки винрарные, хайколор, на полэкрана аж. И все. По этому поводу возиться с оплатой шаровареза? Или искать кряк? А оно надо? Проще 7zip совершенно даром слить. Под *никсами - один хрен, UI'ем выступит mc/Ark/что там еще. Не аргумент.  

> 4) Ubiquity.

Чаво? Каво? google -> Ubiquity выдает весьма интересные результаты. Они не винрарны.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

65. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +/
Сообщение от Иван Иванович Иванов (?), 13-Май-11, 01:20 
> А если бы ещё форматы bz2/gz расширили возможностью включения оглавления лежащего внутри
> tar-а чтобы можно было читать оглавление не разжимая архива (да, это
> автоматизировано, но разжатие-то всё равно всегда делается, что требует временм и
> места) - вообщн была бы красота...

Вы несёте бред.

Почитайте статью о solid сжатии.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

66. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +/
Сообщение от StrangeAttractor (ok), 13-Май-11, 01:28 
>> А если бы ещё форматы bz2/gz расширили возможностью включения оглавления лежащего внутри
>> tar-а чтобы можно было читать оглавление не разжимая архива (да, это
>> автоматизировано, но разжатие-то всё равно всегда делается, что требует временм и
>> места) - вообщн была бы красота...
> Вы несёте бред.
> Почитайте статью о solid сжатии.

Поясните. Что такое solid сжатие знаю и искать и читать целую статью чтобы понять Ваше утверждение не собираюсь.

Ответить | Правка | Наверх | Cообщить модератору

109. "В рамках проекта TheUnarchiver решены проблемы с использован..."  +1 +/
Сообщение от Аноним (-), 14-Май-11, 17:35 
> Вы несёте бред.
> Почитайте статью о solid сжатии.

Почитал. Понял что если включить в начало TAR архива блок с полным списком файлов - то из tar.bz2/tar.xz/tar.lzma можно будет быстро поиметь список файлов, невзирая на solid сжатие.

Проблема лишь в том что сам tar - это по изначальной задумке Tape ARchive. Формат созданный для архивирования на ленту, а потому уповающий на непрерывный и единоразовый доступ к носителю, в стиле слива бэкапов на ленту. Этим и объясняется линейное расположение файлов, без центрального списка, который можно быстро распаковать в начале. Упомянутое дописывание имеет ряд проблем. Когда мы только начинаем жать и пишем в начало файла, мы не знаем сколько файлов и до каких размеров получится сжать и где это будет физически расположено в файле. Поэтому мы не можем заранее построить полноценный блок с списком файлов, их размеров и позиций в архиве, записать и сжать его. Мы не знаем часть информации и узнаем ее лишь по мере создания архива. Поэтому полноценный блок описания списка файлов можно построить лишь когда архивирование уже закончено и все параметры известны (какие файлы удалось заархивировать, в какие позиции они попали, etc). Все бы ничего, но даже для дискового файла это некая проблема: в начале файла УЖЕ есть данные. Некоторые пишут поэтому данную таблицу в хвост файла, но если делать solid сжатие архива, то распаковывать ВСЕ данные до того как получить таблицу - неинтересно. В дисковом файле правда можно изгальнуться с перемещением данных из первых блоков файла в хвост чтобы освободить место для таблицы, записать туда таблицу + сделанную релокацию и в принципе даже прокатит. Для дискового файла, да. Но Tar это ЛЕНТОЧНЫЙ формат! А для лент сие потребует перемотки ленты на начало, перезаписи начальных данных, перемотки в хвост, дозаписи данных. А вот это - жопа. Это - не Tape ARchiver уже с такими мерзкими свойствами. Вообще никак.  

В результате - или сохранятся мезкие свойства формата TAR или это будет уже не TAR и не обеспечит только последовательный доступ к ленте. Если забить на ленты ... тогда наверное и tar'ом это нефиг называть?!

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру