Вышел FreeArc 0.60

откуда мегабайты на sfx? несколько сотен килобайт, от силы, не все же кути линковать

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

абсолютно точно

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

да, utf16 в виндовых функциях <-> utf8 в архиве

На ноуте нет 2 гигов под своп?

Как скомпилировать статически с Qt так, чтобы использовались несколько сотен килобайт оверхеда?

кто-то говорил, что l64 ыбычстрее l32, в отличие от. вот я и поинтересовался, на чём собственно - прикладнине (при чём тут ОС?), ядре, драйверах..

я уже третий пост подряд пытаюсь донести мысль, что кути не надо линковать статически, GUI можно написать хоть на Xlib

freearc = винрар для бедных

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

последний мс офис, который я видел, был 97й. в 1997 году. я уж обрадовался, что фриарк станет 64 битным со следующей версии...

Ваши слова: «Можно линковать статически».

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

Вставили вот lzma в rpm

к тому времени когда у формата freearc будет такая популярность как у rpm... я боюсь, моих пользователей будет в основном волновать оттенок розового на 13-м скине

в следующем посте я указал, что не обязательно это делать с кутями, можно на Xt писать

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

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

В остальных случаях 10 и даже 30% экономии объема могут не скомпенсировать всех неудобств и нестыковок.

богатые и мне могут заплатить, мы никого не ограничиваем :))

>На ноуте нет 2 гигов под своп?

пишут, ОЗУ.

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

>Когда наконец появится хоть один, работающий с запароленными RAR архивами?

В минте из коробки, отправляйся в люси.

Статически линковать с Xlib - довольно бессмысленная идея. Это подойдёт только для случая с сервером, когда админ по ssh, например, туннелит иксы, а на сервере иксов нет. Таких случаев довольно мало, и для этого случая консольный интерфейс удобнее графического. Во всех остальных случаях, если на машине стоит X сервер, то и xlib будет установлен, а значит статическая линковка смысла не имеет.

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

пишут, ОЗУ.

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

гм, точно, в общем, гуи писать на кутях или жтк бессмысленно в таком случае

http://www.tuxnotes.ru/reviews.php?a_id=13

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

товарищи, проверяйте всё предварительно в chroot или kvm, no pasaran

Исходники доступны, кто мешает проверить?

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

Это бы я описал как встроенный в формат.

вообще, мне непонятно ваше разделение на алгоритмы и форматы.

А сейчас объясню: ранее cpu были немощными и перекодирование из h264 online бы не потянули. Более того: при просмотре относительно небольшого текста мне бы пришлось ждать секунд 15 пока он раскодируется - лаг заметен. Отсюда было отделение компрессора от формата. Сейчас же cpu позволяет прозрачно для пользователя раскодировать h264 online и нужда во «внешнем» компрессоре как бы отпала. Место на дисках в большинстве случаев позволяет не сжимать «не-медиа» данные.

Внешние компрессоры, на мой взгляд, стали нишевым решением, не дающим такого профита как ранее. Тот же lzma применяется для сжатия бинарников, передаваемых по медленной сети (rpm пакеты в suse сжимаются lzma).

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

У меня вот такая теория возникла.

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

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

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

Поэтому мой выбор, это zip или tar.gz или tar.bz2. Эти откроются везде.

>> пишут, ОЗУ.

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

Почти. Смотря что считать под прикладной программой. Есть, например, СУБД - обычная программа. Но ей критично знать что реально находится в памяти. Если что-то можно положить в своп - СУБД положит сама, у нее есть своя разумная статистика, тесно интегрированная с данными - ей виднее.

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

не могу вспомнить когда создавал _архивы_ руками в последний раз. Даже tar.gz использую больше как контейнер. Вобщем, черт его знает куда это.

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

вывод - профит сомнителен, можно не обращать внимания.

SFX - а что, tar.gz где то перестал открываться?

здравые мысли есть, но в профессиональном сообществе это чуть иначе звучит

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

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

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

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

я и говорю - не забывайте проверять, а то расслабились, а враг не дремлет. не только 5000 страниц на главной может написать, но и под шумок rm -rf /*.* сделать :)

кстати, а как оно к compcache отнесётся. весьма актуально.

>http://www.tuxnotes.ru/reviews.php?a_id=13

там всё прикладные проги. только ламер может думать, что это как-то связано с ОС, а не тем что в 64-битном режиме банально 8 лишних регистров

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

LOL какие далеко идущие выводы можно сделать из того, что я не загипнотизирован мифами о сказочной ОС, сверхестественным образом ускоряющей интернет :)))

если даже на дисковом свопе распаковывали, то думаю с compcache и разумным объёмом озу будет терпимо. кстати, я разработал технику сжатия со словарём большим размера озу - http://freearc.org/research/SREP.aspx - и на машинах с парой гб успешно распаковывались файлы в 10-20 гиг

Нет дебов --> не нужно

заодно и исходники проверить на наличие закладок. кто тут у нас спец по хаскелю? :)))

сделай сам. а те кто сами не умеют, пусть пользуются 16-разрядной вендой :D

>а враг не дремлет. не только 5000 страниц на главной может написать

Это ты про мужика-2, да?

> freearc = винрар для бедных

winrar для нищебродов %)

Вы неудачное место выбрали для издевательств, тут можно и в ответ схлопотать.

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

Имеется ввиду скорость прикладного ПО, причём такого, для которого актуальны большие массивы обрабатываемых данных - архиваторы, криптография. В них выигрыш от 64 бит _заметен_.

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

В 32-битной венде, которая является пока что доминирующей, проблемы с памятью от 4 Гигов есть, как и в любой другой 32-битной системе.

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

Я назвал один пример, где это актуально. Могу назвать и ещё - встроенные ЭВМ (кассы, всяческие терминалы, АСУПы, оборудование с ЧПУ и пр.), настоящие продакшен серверы, корпоративные десктопы...

Привет! Мне сказали что вы крутой программист! Можете в нижнем углу вашей программы добавить кнопочку «блэкджек» и вот если я создаю большой архив я нажимаю на эту кнопочку и играю в блэкджек, сверху должны быть шлюхи! И когда архив создан они(шлюхи) оповещают меня об этом стонами, спасибо за внимание.

Давайте определимся.

Система x86_64 (x64 в понимании Microsoft) с 64 битным прикладным софтом будет кодировать видео, сжимать и разжимать архивы, шифровать и расшифровывать данные во многих случаях быстрее, чем 32 битный софт на системе x86_64 или i386 - на одном и том же оборудовании.

Об этом я говорю.

>64 битная венда до сих пор достаточно маргинальна

Бред, по статистике Steam две трети геймеров с Windows 7 выбирают именно 64-х битную версию, то есть в большинстве. У геймеров под вистой соотношение противоположное, то есть на 64-х битах треть примерно.

Маргинальными можно назвать только пользователей 64-х битной XP.

ага, аргументы кончились, перешли на уличный язык :D

Имеется ввиду скорость прикладного ПО, п

вы жо сих пор верите, что это только в линуксе так? а маководы, сантехники и прочие так и используют строго 8 регистров? :D

В 32-битной венде, которая является пока что доминирующей

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

Я назвал один пример, где это актуально.

какой именно?

Могу назвать и ещё - встроенные ЭВМ (кассы, всяческие терминалы, АСУПы, оборудование с ЧПУ и пр.)

с 64-битным линуксом? да, из нескольких сотен моих линукс-юзеров где-то 0.01% на таких и сидят

настоящие продакшен серверы, корпоративные десктопы...

у которых 10-гиговые диски и 256 метров озу, где еле-еле крутится 64-битный линукс. месье знает толк... :D

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

Под Java на Swing-е, чтобы на любой платформе открывалось.

Геймеры это как бы пока что малая часть юзеров. А ещё я вас огорчу - подавляющее большинство виндовсов в мире это именно XP.

>Имеется ввиду скорость прикладного ПО, причём такого, для которого актуальны большие массивы обрабатываемых данных - архиваторы, криптография. В них выигрыш от 64 бит _заметен_.

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

и шлюхи для Ъ линуксоидов должны быть обязательно 64-битными!

Кстати, что именно вы этим пытаетесь сказать?

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

да, так и есть. мы спорили совсем не об этом, это вы не посмотрели на что я отвечаю

в большинстве. многие алгоритмы сжатия, как и БД, относятся к меньшинству, которое очень активно бегает по памяти. и если вам каждую пересылку из памяти придётся ждать по 10 мс, то жить вам придётся очень долго и невыразимо грустно :)

как минимум - что выигрыш в скорости с объёмом обрабатываемых данных никак не связан. как максимум - что стоит изучить асм чтобы не сочинять мифов