Вышел FreeArc 0.60

Открой для себя rar, а если серп яйцам мешает^W^W^W наг текстовый задолбет - unrar.

скажи, а скажем девушку ты тоже бросишь, если окажется что у нёе стоит убунта? LOL

в данном случае - 10%. благо что основной алгоритм - lzma, а его 64-битная версия имеется

это мне надо поправить :(

ну мало ли в казахстане донов педров LOL

ага. кстати мне интересно, насколько нужны GUI SFX-ы, и если да - под какую либу их надо делать (gtk, qt...)

> если нужна распаковка на старых машинах, то нужно выбирать режимы поскромнее.

или другой архиватор

а зачем нужна ещё одна ОС? :) 90% хватает винды, но ведь есть ещё и извращенцы :D мне лично не хватает полноценного архиватора с поддержкой lzma. другие люди используют его для кпаоквки игрущек (процентов 90 репаков больших игр сейчас сжимается фриарком). кому-то нужен быстрый архиватиор для бэкапа. ну и т.д., изращенцев в мире очень много, не думай что всем нужно в точности то же, что и тебе

кстати, при встрече передай Кернигану что вместо очередной ОС лучше бы разработал IDE под хаскел

а я не знаю какой у меня архиватор, какой то в наутилус встроен и все

> а зачем нужна ещё одна ОС? :) 90% хватает винды, но ведь есть ещё и извращенцы :D
Я бы ответил, но не хочу разводить оффтопик. Эта тема подробно раскрыта на http://www.linux.org.ru/view-message.jsp?msgid=4393779

у freearc есть специальные ассиметричные реджимы -mx5..-mx9, так что всё равно 7-zip и тем более rar проиграют :)

в любом случае у меня 32битных либ нет и не будет, поэтому желаю скорее обрасти 64 битами, в наш то 21й век.

Практика показывает, что сейчас они в линуксе не особенно нужны. Но если делать на перспективу, то лучше всего что-то минималистичное, обойтись конкретно в линуксе xlib и хорошо продумать диалог указания пути, привязка к тулкиту, вероятно, слишком перегрузит такой sfx. Сейчас же делают консольные sfx, например через dialog.

Цитируем truetester

Поддерживаются ли sfx-архивы пол линуксм?

SFX-linux модуль в дистрибутиве есть. Файл arc.linux.sfx , x86 консольный.

Спасибо.

> да. я собираюсь это поправить, но работы больно много. я вообще не понимаю, как запуск 32-разрядной программы может быть проблемой. в виндах это поддерживается с 92-го года

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

> А чем твоя секта лучше?

Я не состою в сектах, у тебя разыгралась фантазия.

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

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

>Режим максимального сжатия теперь создаёт архивы для распаковки на компьютерах с 1 гб ОЗУ, а новый режим Ультра-сжатия - для распаковки на компьютерах с 2 гб ОЗУ.

хорошие режимы. Я бы еще добавил режим, чтобы распаковка на чужих компах вообще в любом случае вешалась.

> ага. кстати мне интересно, насколько нужны GUI SFX-ы, и если да - под какую либу их надо делать (gtk, qt...)

sfx в принципе нежизнеспособен, т.к. неизвестно заранее на какой архитектуре его будут распаковывать. Более того, даже если взять в качестве архитектуры например i686-only, получаем кучу вкусняшек с потенциально возможной несовместимостью ABI установленных в системе библиотек (glibc, Qt и т.п.) с той версий, с которой линковался данный sfx.

>между прочим, под виндами офис переведён на 64 бита, студия - нет. почему?

потому что и все плагины тоже тогда надо в 64 бита перегонять. А МС это не под силу.

Имхо, консольного хватит. Реальность такова, что ни gtk ни qt не содержатся на 100% линуксовых машин. Даже xlib на серверных машинах зачастую не стоит. Если хочется GUI, то, имхо, xlib и откат на консольный интерфейс если xlib на машине не найден (или не удалось соединиться с X-сервером).

их применяют например при упаковке современных игрущек, которые на машшинах без гига памяти так и так не идут :)

Значит, всё-таки хотите пофлеймить :) В венде много чего встроено, потому весит она чёрте сколько и забивает полезное место (например, в нетбуках с ssd пара гигов - очень даже критично, как и 10% производительности). Вместе с тем, 64 битная венда до сих пор достаточно маргинальна и не даёт особого профита своему владельцу. В Линукс это не так, в большинстве случаев 64 битная сборка дистрибутива оказывается быстрее 32 битной, поддерживает больше ОЗУ без костылей и не приносит особого гемора, а в случае использования только 64битного софта ещё и позволяет экономить место. Потому 32-бит онли софт у многих может вызывать неодобрение, а ваши ссылки на венду даже откровенное раздражение.

нет, потому что 64 бюита в принципе не нужны, ни офису, ни студии

> между прочим, под виндами офис переведён на 64 бита

неужели? это с какого такого года?

>но поставить 64 юита и экономить один-два гига на либах - это по-млему просто юношеский максимализм

Совершенно согласен, только на мой взгляд, использование архиватора, в котором совместимость каждые полгода (может) ломается и для распаковки нужен гиг или два ОЗУ, это в таком случае даже не максимализм...

можно линковать статически

> Потому 32-бит онли софт у многих может вызывать неодобрение, а ваши ссылки на венду даже откровенное раздражение.

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

не пофлеймить а позидеваться над откровенными фанатиками.

64 битная сборка дистрибутива оказывается быстрее 32 битной

эээ, имеется в виду скорость ядра, драйверов или прикладнины?

поддерживает больше ОЗУ

да, в винде это конечно не так. до сих пор 640к, приходится использовать xms или ems

а в случае использования только 64битного софта ещё и позволяет экономить место

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

со след. версии. за новостями надо следить :)

Помнится во времена DOS был архиватор ha, который позиционировался как лучший в сжатии текстов.

Сейчас есть специализированные алгоритмы сжатия текста/видео/something? Или сейчас все интегрируют в сами форматы?

Просто вдруг стало интересно.

>их применяют например при упаковке современных игрущек, которые на машшинах без гига памяти так и так не идут :)

по правде сказать, у нас вообще в этом плане какая-то аномалия. Непонятно с чего и вопреки всякой логике, советские люди вдруг толпой налетают на rar, icq, the bat! и т.п. случайные проекты.

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

эээ, имеется в виду скорость ядра, драйверов или прикладнины?

я замечал, что видео меньше тормозит

насчёт совыместимости полностью согласен - прога пока далеко не для массового пользователя. совместимость кстати не ломается, а старые версии не могут распаковать новые архивы

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

если речь о просмотре филтмов, то это прикладнина, скорость которой от ОС никак не зависит :)

>нет, потому что 64 бюита в принципе не нужны, ни офису, ни студии

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

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

Но, сборка-то в 64-х битной ОС будет 64-х битная

>можно линковать статически

архив сильно потолстеет, что не очень хорошо, особенно для данного типа файлов.

ну например h264 :)

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

ну понятно, что студию пишут в индии, а линуксы исключительно в штатх. потому и цена так различается :D

Ели уж очень охота гуи, то можно и на икстулкит написать

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

>насчёт совыместимости полностью согласен - прога пока далеко не для массового пользователя. совместимость кстати не ломается, а старые версии не могут распаковать новые архивы

ну это еще ничего, хотя и иногда страшно неудобно. Вставили вот lzma в rpm и теперь при бэкпорте приходится ручками распаковывать рпмники.

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

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

так, а мы о чём собственно говоря спорим? о том, что x86_64 на некоторых задачах производительней ix86? или о том, что само ядро быстрее на x86_64 работает?

>в виндах прогам доступны все те же самые регистры и операции, мамой клянусь :)

ну тогда венды сумели перехачить процессор...

SFX архив? Ну разве что он будет весить гигабайты, да и то мегабайтов 10-15 отдавать под статику. Или я не те размеры представляю?

«суди не вышу сапога» :D причина в том, что программа как ни странно пакует гораздо лучше 7-zip'а именно большие объхмы данных - сотни и тысячи мегабайт. у 7-zip словарь на порядко меньше со всеми вытекающими отсюда последствиями: размер архива freearc оказывается процентов на 10-30 меньше

ну и насчёт налетели - наоборот, длительное время это была тщательно скрываемая технология, используемая наиболее пронырливыми товарищами

>локаль файлсистемы можно настраивать (опция -scf кажись), но в архив она не вписывается. в архиве, предполагается, всё всегда в utf-8

предполагается, это значит работает только в системах с utf-8 или с вручную заданой перекодировкой (-scf)? без проверки на валидность utf-8?

А в винде-то нормально автоматически перекодирует?

вы таки уверены, что в 64-битном линуксе регистров больше, чем в win64?

до чего фанатизм может-то довести... :D