» FreeArc (часть 4)

Pedro2007
и тебе спасибо, что редактируешь сообщения

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

вообще прикрутить хотя бы сообщение о слишком длинном имени файла - хорошая идея

вообще из предложенного мне понравились идеи:
1. при выборе метода сжатия сразу писать прогнозируемое время
2. экспорт настроек операции в .bat

Цитата:

Вы когда палнируте SREP интегрировать?

не скоро. технически, сжатие там довольно необычно, без временных файлов не обойтись


Цитата:

мб sfx не паковать юпиксом?

для тех, кто не разбирается в тонкостях, мы даём готовый мелкий exe. кто разбирается - может распаковать, отредактировать и перепаковать как ему надо - их лишний шаг не напряжёт

Добавлено:
кстати, я на днях тестировал упаковку на ram-диске "типичного" бинарного файла (это установленный ms office 2008, собранный в один файл). вот результаты на моём 2600k@4.6:


Код: I:\>arc a a MsOfficeBCJ.obj -m1 -t ; a a MsOfficeBCJ.obj -m2 -t ; a a MsOfficeBCJ.obj -m3 -t ; a a MsOfficeBCJ.obj -m4 -t

Compressed 1 file, 810,411,321 => 435,915,683 bytes. Ratio 53.7%
Compression time: cpu 12.21 secs, real 1.69 secs. Speed 479,506 kB/s
Testing time: cpu 8.17 secs, real 1.13 secs. Speed 716,503 kB/s

Compressed 1 file, 810,411,321 => 354,936,466 bytes. Ratio 43.7%
Compression time: cpu 37.67 secs, real 5.41 secs. Speed 149,707 kB/s
Testing time: cpu 9.34 secs, real 1.30 secs. Speed 621,922 kB/s

Compressed 1 file, 810,411,321 => 340,488,887 bytes. Ratio 42.0%
Compression time: cpu 80.22 secs, real 11.83 secs. Speed 68,489 kB/s
Testing time: cpu 23.67 secs, real 3.22 secs. Speed 251,432 kB/s

Compressed 1 file, 810,411,321 => 326,333,602 bytes. Ratio 40.2%
Compression time: cpu 184.69 secs, real 24.75 secs. Speed 32,747 kB/s
Testing time: cpu 22.53 secs, real 3.45 secs. Speed 235,093 kB/s

Bulat_Ziganshin

Цитата:

2. экспорт настроек операции в .bat

Спасибо, что обратили внимание на это. Я думаю что это многим полезно будет.
Булат, подумайте пожалуйста над оформлением, мне кажется, что простота на первых парах - спасет мир. Упомяну еще раз перечень софта, на который бы я обратил внимание в плане простоты и в то же время удобства в дизайне - это TrueCrypt, InsidePro.PasswordsPro, PSI+. Там масса настроек, которые вполне себе уживаются как для новичков, так и для продвинутых пользователей.
Хотел бы спросить - какие есть еще варианты по реализации информации для восстановления? В плане, у РАРа сделано на ХОRе, а как можно это все дело улучшить в ARCe?

Цитата:

cpu 8.17 secs, real 1.13 secs

8 ядер?)

Добавлено:
опять я невнимательно прочитал
Цитата:

на моём 2600k@4.6

Добавлено:
у среднего пользователя все равно скорость будет раза в 4 ниже.

juvaforza

Цитата:

Разработчики GIMP, как раз, как-то ушли от проблем с раскладкой.

что-то не заметил gimp-2.6.11.
может у Вас особенная сборка, дайте линк?

vasulpr
к сожалению, никто твои предложения не прокомментировал. я со своей стороны смотрю и вижу только предложение вынести шифрование в отдельный таб. с одной стороны, да - сейчас выбор метода шифрования без ввода пароля выглядит довольно странно. с другой - сейчас можно один раз выставить пароль и дальше шифровать с ним, быстро ставя галочку в первой закладке

да, ещё ты там убрал выбор комментария. комментарий тоже сейчас вводится чертовски неинтуитивно, и это надо целиком переделывать

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

Добавлено:

Цитата:

Я думаю что это многим полезно будет.

да, идея оригинальная и к тому же легко реализуемая - на самом деле и сейчас можно вытаскивать комстроку из логфайла

а как конкретно лучше сделать - добавить в диалог кнопку "save as...", или сделать её одной из командных кнопок (как ok/cancel), или сделать где-то список УЖЕ ВЫПОЛНЕННЫХ команд, из которого можно сохранять?


Цитата:

Булат, подумайте пожалуйста над оформлением

чукча - не читатель. во-первых, у меня плохо с дизайном/юзабилити вообще, во-вторых, я сделал удобную для себя вещь - комстроку. я именно от вас жду обсуждения оформления


Цитата:

какие есть еще варианты по реализации информации для восстановления?

исходники par2-based утилит. поищите выше

Блин, да назови ты наконец свою версией 7.0 а то половина знакомых вообще отказываются из-за твоих шестёрок пользоваться твоим архиватором.

Ну да, это прикольно, но если хочешь побольше известности и пожертвований - быстрее выпускай 7.0 версию и тогда и я присоединюсь

Удачи.


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

Profrager
Все-равно потрясная скорость, но бесспорно - ориентироваться нужно на средние мощности компа.
Bulat_Ziganshin

Цитата:

переименовать этот режим в instant (мгновенное) сжатие

Да, так было бы правильнее. я обеими руками за. З.Ы. с нетерпением жду встроенного srep

BESTWIZARD1

Цитата:

Блин, да назови ты наконец свою версией 7.0 а то половина знакомых вообще отказываются из-за твоих шестёрок пользоваться твоим архиватором.

Ну да, это прикольно, но если хочешь побольше известности и пожертвований - быстрее выпускай 7.0 версию и тогда и я присоединюсь

реально бред не пользоваться программой только потому, что там какие то спецефические цифры в версии. Она от этого ни лучше, ни хуже не становится. Зачем находиться под влиянием суеверий и предрассудков, если это только мешает жить?

вот офиц.ответ на мой запрос по этом Бакдору... сказали исправят... читать по сссылке снизу вверх)))

Profrager

Цитата:

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

а на статистику суеверия не действуют!

Bulat_Ziganshin

Цитата:

а как конкретно лучше сделать - добавить в диалог кнопку "save as...", или сделать её одной из командных кнопок (как ok/cancel), или сделать где-то список УЖЕ ВЫПОЛНЕННЫХ команд, из которого можно сохранять?

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

Цитата:

я со своей стороны смотрю и вижу только предложение вынести шифрование в отдельный таб

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

Цитата:

я именно от вас жду обсуждения оформления

Мне кажется, что для начала можно в шапке и на сайте повесить "Объявление" о том, что проводится конкурс иконок для новой версии, и отобрать их. Можно попросить инвайт или написать в песочницу Хабра об ARC, там любят опенсорс и там же тоже написать об вопросах юзабилити и иконок, т.к. дизайнеров полно, и наверняка найдутся те, кто готовы внести свой вклад в сообщество опенсорс, тем более отечественного коллеги по коду.

Bulat_Ziganshin

Цитата:

учитывая что флешка всё равно медленней винта - вероятно выгодней увеличить степень сжатия. попробуй -m2 и -m2b

да иногда не сжимается, а русурсов на разжатие требуется больше.

Вопрос на будущее: планируется ли шифрование по ГОСТ 28147-89 ?
Например лицензия OpenSSL позволяет заимствовать код, если нет желания самому делать.

мне один в ответ то же отвечали, хоть и другой человек. видимо, всё уже до предела отработано )

думаю, что этот бакдор запаковали в мой инсталлер, касперы и авасты лоханулись и определили его по sfx-части, а большинство других - по оверлею где собственно запакован бакдор был. из-за этого пролетали все sfx-ы, где был тот кусок кода, который они задетектили

собственно каспер уже исправлен

а что делать я придумал - надо автоматом на VT слать каждодневно все инсталлеры и следить за появлением новых false positives. api у них есть, есть вероятно и какой-то сервис

egor23

Цитата:

что-то не заметил gimp-2.6.11.

Да, ты прав

snkreg

Цитата:

Хотел бы спросить - какие есть еще варианты по реализации информации для восстановления?

RSC32 например.
http://forum.ru-board.com/topic.cgi?forum=5&topic=24050&glp

Цитата:

а что делать я придумал - надо автоматом на VT слать каждодневно все инсталлеры и следить за появлением новых false positives. api у них есть, есть вероятно и какой-то сервис

Так и поступим. Я подключаюсь.
Кста, как и обещал - выкроил время и дозвонился в Есет - девочки мозг выносили, потом соединили с "тех. специалистом", который тупил, сказал что ложное срабатывание эвристики, после чего я ему сказал о Zботе Trojan-Spy.Win32.Zbot, он потупил, резко включился и сказал что видит письма с подобными жалобами, и что приняты меры, в ближайшее время исправят. я решил не проболжать пустую болтовню, моя задача проинформить их, и чтобы они поняли что их и звонками достанут. Единственное, тупанул - надо было узнать его ФИО, чтобы поответственнее отнесся. Предлагаю всем, кому небезразлична судьба проекта - по возможности потратить несколько минут и позвонить антивирям, ну а у кого нет возможности или просто впадлу - хоть письма напишите.

Вопрос по методам -mx и -mex9. Если я правильно понял, то это одинаковые методы сжатия, с той лишь разницей, что -mx это двухпоточное сжатие, а -mex9 это многопоточное (например 4 как у меня). Так ли это?

да, кстати - посмотрел я на инсталяторы в целом. картина та же - 0.666 в полном порядке, на 0.67 куча ругани:
http://www.virustotal.com/file-scan/report.html?id=cff7c9a17ea707c7acd53c141bc1610a425456276b9021c06f4113043e810403-1315333863
http://www.virustotal.com/file-scan/report.html?id=49c3310b4a9d14f5d0a09c3095aedcdd0c19c8fe427703faf4630b6034ec608d-1315333596

похоже, что 666-ю версию пользователи уже добили багрепортами, а 67-я мало кем используется и её многие детектят как вирус. тут ещё есть такая фигня - симантек например помечает как suspicious любой exe, которого у него нет в базе. т.е. первые пару месяцев прога под подозрением, потом юзеры их задалбливают и они переводят её в "проверенные". понятно, что для редких exe этого так и не происходит

Paramon111
у них общий базовый алгоритм, но -mex9 бьёт данные на блоки, которые сжимаются независимо, поэтому сжатие хуже -mx9


Цитата:

RSC32 например.

напомнило мне один из розыгрышей Стива Возняка


Цитата:

проводится конкурс иконок для новой версии

конкурс уже был. а вот поддержки иконок в fa до сих пор нет


Цитата:

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

дело в том, что такая логика применима и ко всем остальным опциям. recovery record или финализация архива нужны тоже далеко не каждый день

Цитата:

симантек например помечает как suspicious любой exe

Наверное не так брутально, а просто если ехешник чуть отличается от "стандартного", тогда под подозрение попадает.
В любом случае просто надо принять к сведению - что по выходу новой версии - закидывать их реппортами, пока не привыкнут и сами не будут отслеживать даже ночные билды))

Вопрос назрел по причине весьма интересной формулировки справки по FreeArc касательно количества используемой памяти. Что интересно, конкретного ответа на мой вопрос в справке я не нашёл, а тема использования памяти описывается весьма условно.

Читаем в справке:
Цитата:

Максимальное сжатие
  –m9x – самое мощное асимметричное сжатие, доступное при вашем объёме памяти. При распаковке будет использоваться в 8 раз меньше памяти, и она будет идти гораздо быстрее, чем упаковка. Этот режим сжатия удобен для создания дистрибутивов и т.п.

(интересующий момент выделен цветом).

А теперь рассуждаем логически.
1. Имеем х64 ОС с 12 ГБ оперативки.
2. Поскольку исполнялка - 32-битная, следовательно, на неё может быть выделено не более двух гигов оперативы (определено опытным путём). Отсюда, верхняя планка памяти для упаковки стремится к 2048 МБ.
3. Если сказано, что на архив (8 гигов инфы, создан по методу "-m9x") при распаковке будет использовано в 8 раз меньше памяти, получаем, что нужно будет 2048МБ/8=256МБ.

Теперь же, собственно, вопросы:

1. Действительно ли размер словаря составит тоже 256 МБ? (столько же, как видим, потребуется для распаковки)

2. Хватит ли для распаковки такого архива 512 МБайт оперативы? (т.е., часть скушает ОСька, и где-то около 300 свободно, как раз хватить должно, но мало ли...)

з.ы.
Если я где-то что-то упустил или допустил ошибку - прошу поправить.

для справки
в Касперски AV (6.0.4.142.a,e,f) for Windows WS (WW MP4) (база обновляется каждую неделю)
у меня не нашел ни в одном sfx-модуле какой либо вирус
хотя дома что kis2010 что kis2012 определяли как вирус installer installer-delete (может еще какой то, не помню уже)

insorg
есть три метода сжатия:
-mx, он же -m9
-m9x, он же -mx9
-mex9

-mex9 - многопоточный, увеличивает скорость за счёт уменьшения сжатия. вам это, как я понимаю, неинтересно

-m9 - симметричный, т.е. памяти при распаковке и упаковке нужно одинаково

-m9x - асимметричный, позволяет достичь макс. степени сжатия при заданном кол-ве памяти для распаковки

если вас интересует именно последнее, то используйте -m9x -md256m - и вам будет гарантировано, что при распаковке нужно будет не больше 256мб памяти

Из моего опыта общения с тех. поддержкой DrWeb...
Одна моя утилита была упакована в 7zSFX и на этот SFX ругался DrWeb.
Разобрав ее на части определил, что ругань идет на добропорядочную утилиту NirCmd версию точно не помню, но пусть это будет 1.83. Заменил версию на 1.82 - ругань пропала.
Переписка с "ветеринарами":
Вопрос: Почему DrWeb ругается на добропорядочную утилиту NirCmd? Утилита мирная, давно известная, что в ней опасного?
Ответ: Она умеет скрывать консольные окна и тем опасна.
Вопрос: Но ведь скрывать консольные окна умеют и другие утилиты! Что в этом криминального? Почему именно NirCmd попала под подозрение?
Ответ: Она нам встретилась в "дурной компании".
Вопрос: Так Вы собираетесь это дело исправлять, реабилитировать NirCmd? Что мне делать, если я ее использую для своих мирных целей?
Ответ: Не собираемся. Перейдите на новую версию NirCmd, у них вроде версия 1.84 вышла и она пока не занесена у нас в базы.
Вопрос: А где гарантия, что и новая версия со временем не попадет в ваши базы? Может через неделю и 1.84 там очутится?
Ответ: Может, если будет встречена в "дурной компании".

Продолжать далее эту переписку я не видел смысла...

К чему это я?
Булат, может имеет смысл выпустить новую альфу (например, 0.68)? Может перекомпиляция собьет антивирусы с толку и они перестанут детектить SFX модули как зловреды?
Понимаю, что это не панацея, но долбить тех. поддержку множества антивирусов с их дубовой логикой может оказаться себе дороже с учетом сил и нервов потраченных на это.

arc l ftp://test.arc
?

Bulat_Ziganshin
Немного не так.
Меня интересует самый-самый мощный алгоритм сжатия (без внешних упаковщиков), который не потребует столько памяти при распаковке, сколько нужно было для упаковки.
Как я понимял, асинхронка "-m9x" - это и есть что нужно.
Вопрос в том, какой максимум памяти он может потребовать на больших обьёмах инфы (напр., 8 гигов при 20…16000 файлов).

Может кто обьяснить почему precomp не все zip архивы распаковывает???


Цитата:

Precomp v0.4.1 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2010 by Christian Schneider

Input file: D:\TRASH\precomp\iw_00.iwd
Output file: D:\TRASH\precomp\iw_00.pcf

Using PACKJPG.DLL for JPG recompression.

--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg

100.0% - New size: 3425029 instead of 3872030

Done.
Time: 2 minutes, 7 seconds

Recompressed streams: 1/1245
ZIP streams: 1/1220
zLib streams (slow mode): 0/25

You can speed up Precomp for THIS FILE with these parameters:
-zl11 -l0

Fast mode does exactly the same for this file, only faster.

В итоге файл получается даже чуть меньше и жмется гораздо хуже чем исходный

Bulat_Ziganshin
Реально ли сделать чтобы метод -mx использовал больше 2-х потоков? Тогда и -mex9 будет не нужен ))

loky88

Цитата:

Может кто обьяснить почему precomp не все zip архивы распаковывает?

Цитата:

FreeArc: бесплатный open-source архиватор

Цитата:

В итоге файл получается даже чуть меньше и жмется гораздо хуже чем исходный

Потому что мануал читать нужно.