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

если только за этим стандартом не стоят люди в дорогих костюмах (как в случае с systemd).

скорость ... распаковки - 500 Мб/сек на ядро

но тот же xz распаковывает на моём недопроцессоре >4000Мб/s, те 1000Мб/ядро. чяднт?

Что за процессор и что за данные? Нули что-ли?

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

чёт я подупоролся, отбой

А какие каналы? Я видел логи, которые плохо помещались в канал SATA.

А какие каналы?

Сетевые, вестимо.

Я видел логи, которые плохо помещались в канал SATA.

Знатный адокЪ. Зачем такие объёмы писать, если читать их всё равно нереально?

Ну почему нереально, все реально. Сетевые каналы тоже разные бывают, последнее время эти «фигачь JS на 6МБ, у всех Core i7 и оптика» тоже раздражает, когда 16кб/с с дропами.

Так, на процессоре Core i5-4300U с частотой 1.9 GHz новый алгоритм обеспечивает скорость сжатия в 201 Мб/сек при коэффициенте 2.872, и скорость распаковки на уровне 498 Мб/сек.

Круто

Совсем уже с ума посходили. Новость про алгоритм, всё равно упорно обсуждают systemd.

последнее время эти «фигачь JS на 6МБ, у всех Core i7 и оптика» тоже раздражает, когда 16кб/с с дропами.

О да, большой привет EDGE при нестабильном приёме.

Да, знаешь как на нем классно работает, например, Asana?

Нет, но видел сайты, у которых на нестабильном канале таймаут соединения гарантированно истекает раньше, чем начнётся отрисовка страницы.

Изменения поведения умолчальных функций ебилда(src_*, pkg_*), а также введения новых функций(планируемое разделение src_unpack на на собственно src_unpack и src_fetch) в самом portage недопускаются после EAPI feature freeze. Отсюда и предложение сделать поддержку в eclass-е, а потом перенести её в дефолтный src_unpack в новом EAPI.

Так было сделано с .xz для EAPI 3.

Я отвечал на комментарий человека, который предполагает что тарболлы до сих пор в основном пакуют в .gz и .bz2, а это не так - ты уже привёл пример, что .xz тоже наравне

Try to use the richness of the Russian language

Экий ты недогадливый! «Беспотерьный» — это пример сжатия твоей фразы этим алгоритмом :)

Ну что я могу сказать...всё понтяно, но так крииво, терпения нет.

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

Онанимные аналитеги ЛОРа признали ЭТО ненужным! Ну и что, что поделия аффтара (lz4) используются в rip zfs, в сквошфс https://github.com/torvalds/linux/commit/7a02d089695a1217992434f03a78aa32bad8... и запиливаются в ненужно-фс btrfs https://btrfs.wiki.kernel.org/index.php/Compression#Are_there_other_compressi... ??
Все равно НИНУЖНА!!!
И бенчи ну абсолютно непонятные!
Пруфец: https://github.com/Cyan4973/zstd

For a taste of its performance, here are a few benchmark numbers, completed on a Core i5-4300U @ 1.9 GHz, using fsbench 0.14.3[ http://encode.ru/threads/1371-Filesystem-benchmark?p=34029&viewfull=1#pos... ], an open-source benchmark program by m^2.
Name	Ratio	C.speed	D.speed
MB/s	MB/s
zlib 1.2.8 -6	3.099	18	275
ZSTD	2.872	201	498
zlib 1.2.8 -1	2.730	58	250
LZ4 HC r127	2.720	26	1720
QuickLZ 1.5.1b6	2.237	323	373
LZO 2.06	2.106	351	510
Snappy 1.1.0	2.091	238	964
LZ4 r127	2.084	370	1590
LZF 3.6	2.077	220	502

да еще и на абсолютно топовом железе i5-4300U (U=ultra high end)!

Не нужно. В 7z скорость распаковки упирается в винчестер, а жертвовать степенью сжатия ради скорости не хочу

xz c -9 давно пользовали?

где? из упомянутых там только zlib

сравнивали же кучу реализаций. Сжатие от 2 до 3.

Попробуй упаковывать, а не распаковывать.

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

Результаты сабжа очень хороши. Степень компрессии почти как у gzip, но работает в 10 раз быстрее.

gzip 20Mb/s, а у сабжа 200. bzip2 еще более тормозный.

Когда уже в браузеры/вебсерверы наконец встроят человеческие алгоритмы сжатия/распаковки статики на лету? До сих пор поддерживается только gzip. Где lz4, lzo, snappy?

Попробуй потоньше.

Какая система, такие и шутки.

Ты хочешь и здесь развести срач? :]

Ты хочешь и здесь развести срач? :]

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

Так что сжимали-то? Скажем, /dev/zero можно сжать с бесконечным коэффициентом сжатия за минимальное время, а /dev/urandom сколько времени ни сжимай, больше 1 не получишь. Все эти цифры зависят от того, что сжимали.

Да ядро linux сжимали, успокойтесь. Исходники.

Спасибо, теперь я спокоен. Пойду спать.

беспотерьный

Нет такого слова в русском языке. Если хотите одним словом описать, используйте слова «безутратный», «бестратный» или «безрасходный».

Проверено: Shaman007 (25.01.2015 17:24:51)

позорник

На самом деле нужна: разгрузка канала при незагруженном CPU.

Но уже есть bzip, zip, gz, 7z, зачем ещё один такой-же велосипед?

Не такой же. Тесты посмотри.

Обычно нужна либо большая скорость упаковки/распаковки, либо на скорость наплевать и нужна наибольшая степень сжатия. А этот алгоритм ни туда ни сюда — и скорость меньше, и степень сжатия не та.

Впрочем пусть пилят, жить мне это не мешает.

Абсолютные - да. А относительные - куда меньше. Очевидно, что если xz выжал тройку, то 2,7 - отличный результат при том, что скорость работы десятикратна. Понятно, что на других наборах данных результаты могут быть иными, но для начала знакомства сравнения известных алгоритмов с новичком вполне достаточно.

Скорость же на порядки отличается.

используйте слова «безутратный», «бестратный» или «безрасходный».

Исходники ваши лежали здесь

Теперь нет их частично

Утрата печальна

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

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

-9 --extreme же

Судя по картинкам, говноподелие подтеринга за рубежом тоже находит адекватную оценку.

Используй CentOS 6, поддержка до 2020 года, стабильно и хорошо для динозавриков.

беспотерьный

Возможно, вы имели в виду: беспоттерный.

Для даз банных.

Опять_сжимаешь.jpg

pacman -S

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

Плюсую. «Алгоритм сжатия без потерь» - было бы гораздо лучше.

Теперь система будет грузиться на 0,2 сек быстрее?