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

"Эксперимент с использованием SQLite в качестве контейнера для архивирования файлов"	+/–
Сообщение от opennews (??), 25-Мрт-24, 12:51
Проект Pack предпринял попытку создания формата для архивирования файлов, построенного на базе библиотеки SQLite и алгоритма сжатия ZSTD (Zstandard). Подготовленный прототип, написанный на языке Pascal и распространяемый под лицензией Apache 2.0, обогнал по скорости создания архивов наиболее распространённые архиваторы, при том, что его работа сводилась к чтению данных, сжатию библиотекой libzstd и выполнению SQL-операций по добавлению сжатых данных в файл с БД SQLite... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60842
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+4 +/–
Сообщение от Guest (??), 25-Мрт-24, 12:51
А почему бы не исолпльзовать tar с zstd? Ну и для 7z где-то были эксперименты с zstd.
Ответить | Правка | Наверх | Cообщить модератору

	56. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+2 +/–
	Сообщение от Lui Kang (?), 25-Мрт-24, 19:07
	Степени сжатия 7z можно достичь, используя xz, который по-умолчанию обычно уже есть в системе и tar умеет создавать tar.xz, а 7z потребует отдельной установки. xz и 7z оба используют алгоритм LZMA2 по умолчанию. Но если сравнивать что круче в одних и тех же условиях, zstd или LZMA2, то всегда зависит от самих файлов.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от _oleg_ (ok), 26-Мрт-24, 13:46
	tar умеет создавать всё и всегда: tar -c .... | xz > file.txz ;-)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от гыгы (?), 28-Мрт-24, 14:00
	тем временем:      -J, --xz              (c mode only) Compress the resulting archive with xz(1).  In              extract or list modes, this option is ignored.  Note that this              tar implementation recognizes XZ compression automatically when              reading archives. tar(1) P.S. ;-)
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от _oleg_ (ok), 28-Мрт-24, 15:16
	> тем временем: >      -J, --xz Что ты этим хотел сказать?
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от гыгы (?), 03-Апр-24, 13:34
	>> тем временем: >>      -J, --xz > Что ты этим хотел сказать? а ты догадайся. подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от _oleg_ (ok), 03-Апр-24, 13:40
	>>> тем временем: >>>      -J, --xz >> Что ты этим хотел сказать? > а ты догадайся. > подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar :FACEPALM: Возьми с полки пирожок. Дальше-то что? Раскрой свою мысль. Или тебя похвалить, что ты способен скопировать часть текста из man-страницы?
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (111), 03-Апр-24, 15:26
	Похвали, конечно. Трудно что ли?
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от _oleg_ (ok), 03-Апр-24, 15:39
	> Похвали, конечно. Трудно что ли? Да что это я, действительно. Молодец!
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от гыгы (?), 04-Апр-24, 11:19
	>>>> тем временем: >>>>      -J, --xz >>> Что ты этим хотел сказать? >> а ты догадайся. >> подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar > :FACEPALM: Возьми с полки пирожок. Дальше-то что? Раскрой свою мысль. Или тебя > похвалить, что ты способен скопировать часть текста из man-страницы? мысль проста: вые?ся нужно уметь. ты - не умеешь. хотя, если ты из банды cat somefile | grep something то, кажется, я зря теряю время p.s ;-)
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	114. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от _oleg_ (ok), 16-Апр-24, 12:59
	> мысль проста: вые?ся нужно уметь. ты - не умеешь. хотя, если ты > из банды cat somefile | grep something то, кажется, я зря > теряю время > p.s ;-) Аха :-). Мда. Скопировал кусок man'а, выдал какую-то невероятную мысль. Что хотел, зачем писал - не понятно.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от anonymous (??), 31-Мрт-24, 21:01
	Это тоже самое.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

2. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+5 +/–
Сообщение от Аноним (2), 25-Мрт-24, 12:55
Победил 7z. Пофиг, что затратил 54.2 с, зато сильнее всех пожмакал.
Ответить | Правка | Наверх | Cообщить модератору

	28. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+8 +/–
	Сообщение от Аноним (28), 25-Мрт-24, 14:07
	В современных реалиях быстрее будет чуть больше скачать, но быстрее распаковать
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–9 +/–
	Сообщение от Аноним (53), 25-Мрт-24, 18:21
	Да не факт! Вы что, из америки где "везде есть интернет, электричество и паркинг"?? Люди могут и на 8Мбит сидеть - им не нужны ГИГАБАЙТЫ инфы, которую кто-то никак не может сжать.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от tty0 (?), 25-Мрт-24, 23:23
	Мы из России. Тут интернет плохой в небольших удаленных поселках. Но 1МБ/с -- это вообще вполне сносно и не напряжно в рамках дачного поселка в 30км от города.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+2 +/–
	Сообщение от Аноним (42), 25-Мрт-24, 17:11
	Сомнительное соотношение скорости сжатия к размеру файла и скорости скачивания. У меня 100 мегабит етхернета быстрее работает чем большинство флешек лет 10 назад.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	60. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (60), 25-Мрт-24, 20:06
	Тогда уж xz. Только там еще дольше)
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	62. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (62), 25-Мрт-24, 20:11
	Там тот же lzma только в формате потока, поточные компрессоры всегда будут давать результат хуже архиватора и иметь меньшую гибкость, но например они позволяют сжать тарбол со всеми атрибутами в него сохранёнными. Конечно, 7z/rar тоже позволяют запаковать тарбол, но они являются архиваторами со своей по-файловой логикой и тут стоит проверить здоровье.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–1 +/–
	Сообщение от Аноним (62), 25-Мрт-24, 20:08
	7z не дедуплицирует данные, поэтому годится только для маленьких и скучных наборов (без расширенных атрибутов, тегов, времени изменения/доступа и прочего подобного). А результат на пару килобайт лучше достигается совершенно дефективным форматом файла.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	72. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от fuggy (ok), 25-Мрт-24, 22:46
	Ему это не надо, он это умеет на уровне алгоритма словаря с параметром qs. Если словарь достаточного размера. Умеет атрибуты NTFS потоки. С атрибутами файла есть недостатки, потому что 7z не совсем из мира unix way.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (62), 25-Мрт-24, 22:50
	Если словарь достаточного размера. Типичный архив в него не влезает, кроме того, ресурсов намного больше необходимо (и для упаковки и для распаковки) и в многопотоке прогрессия там не очень приятная.
	Ответить | Правка | Наверх | Cообщить модератору

3. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (3), 25-Мрт-24, 12:58
Джипеги же жали, да?))
Ответить | Правка | Наверх | Cообщить модератору

4. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от GhostX (?), 25-Мрт-24, 13:00
rar одного размера с zip? Подозрительно. rar обычно лучше сжимает.
Ответить | Правка | Наверх | Cообщить модератору

	10. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+5 +/–
	Сообщение от ануснимус (?), 25-Мрт-24, 13:14
	Разный же! 253 и 235 Мб
	Ответить | Правка | Наверх | Cообщить модератору

5. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (3), 25-Мрт-24, 13:04
В отрыве от возможностей в мейнстриме это всё весело, но довольно бессмысленно. Отдельно интересно посмотреть бенчмарк всех этих весёлых алгоритмов на разных типах данных и на разных выборках (например, что если нужно извлечь только один файл из сета, либо обновить один файл)
Ответить | Правка | Наверх | Cообщить модератору

	14. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+2 +/–
	Сообщение от человек (??), 25-Мрт-24, 13:19
	С одной стороны соглашусь, с другой нет. SQLite поставляется во всех массовых дистрибутивах систем и языков программирования, и сделать возможность создания такого арзива достаточно легко и не требует наличия специфических зависимостей, так что жизнь у проекто точно возможна, но как мы знаем, это далеко даже не 25%. Сколько проектов всяких интересных по сжатию умирало из-за отсутствия поддержки в меинстриме
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от Аноним (18), 25-Мрт-24, 13:35
	Скулайт он как питон, второй лучший вариант в любой сфере. Только тут задачи применимые к базе данных. Но всегда есть первый вариант.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–1 +/–
	Сообщение от Аноним (84), 26-Мрт-24, 02:38
	>pickle поставляется во всех массовых дистрибутивах Python, и сделать возможность создания такого файла с сериализацией достаточно легко и не требует наличия специфических зависимостей Отлично, давайте использовать везде pickle, зачем нам какие-то JSON, CBOR, npy, safetensors, ведь это надо код писать, а тут всё в стандартной библиотеке! Давайте выпилим из либ код ненужных сериализаций и десериализаций, и будем просто использовать pickle!
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	54. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (53), 25-Мрт-24, 18:27
	Тут нечего смотреть! Бенчи Сыкулита будут ±1% от того архиватора, который под капотом (на ЕДИНИЧНЫХ файлах). Главное - такой формат позволяет БЫСТРЫЙ доступ к любому файлу, что может быть полезно для каких-нть утилит синхронизации или просто "обновление бэкапа".
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

6. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–1 +/–
Сообщение от Аноним (3), 25-Мрт-24, 13:06
Вообще они немножко опоздали, таких штук было уже навалом https://github.com/phiresky/sqlite-zstd
Ответить | Правка | Наверх | Cообщить модератору

	9. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–1 +/–
	Сообщение от YetAnotherOnanym (ok), 25-Мрт-24, 13:10
	Душнила. Весь кайф поломал :D
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+3 +/–
	Сообщение от Аноним (13), 25-Мрт-24, 13:17
	В новости речь про воссоздание архиватора на базе SQLite, а sqlite-zstd - дополнение для прозрачного сжатия записей в SQLite.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	27. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (27), 25-Мрт-24, 13:47
	Ну раз пошла такая пьянка ...  https://codeberg.org/KOLANICH-libs/Cache.py
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (7), 25-Мрт-24, 13:09
жду реализации для http-статики =) в духе времени будет
Ответить | Правка | Наверх | Cообщить модератору

	37. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от Алкоголизм (?), 25-Мрт-24, 15:02
	Для веб-архивирования. Как раз есть аддон SingleFile, который выгружает все ресурсы страницы (стили/графику), и инлайнит её в html, кодируя в base64. И есть на его базе отдельный SingleFileZ, который формирует zip-архив, и аналогичным образом вкладывает в html-страницу вместе со скриптом на js для распаковки и рендера. Тут можно сделать что-то подобное, но вложив в html-страницу БД SQLite, и скрипт для доступа к ней. С поддержкой сжатия БД. Хотя бы в рамках эксперимента и веществ.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от fuggy (ok), 26-Мрт-24, 15:41
	https://wiki.openzim.org/wiki/ZIM_file_format со сжатием, есть просмотрщики. При этом всё умно по категориям ресурсов распихивает, а не тупо в Base64 кодирует.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	102. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от merv (?), 26-Мрт-24, 21:59
	Только нет вменяемых средств создания.
	Ответить | Правка | Наверх | Cообщить модератору

8. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+6 +/–
Сообщение от YetAnotherOnanym (ok), 25-Мрт-24, 13:09
> При сжатии каталога с 81 тысячей файлов, общим размером 1.25 ГБ, pack оказался быстрее утилиты ZIP в 112 раз, выполнив операцию за 1.3 секунды против 146 секунд у ZIP Подозреваю, первым замерили скорость zip, и файлы он читал с диска, а после него запустили pack и файлы он брал из кэша. Ничем другим такую разницу объяснить невозможно.
Ответить | Правка | Наверх | Cообщить модератору

	86. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (86), 26-Мрт-24, 09:06
	То, что Pack оказался настолько быстрее Zip-а, конечно, подозрительно, но пусть (разные алгоритмы сжатия с многопоточность ю в Zstd и т.п.). Но то, что tar.gz с Deflate оказался в несколько раз быстрее, чем Zip с таким же Deflate (размер тарболла оказался даже несколько меньше, т.е. дело явно не в разных степенях сжатия), лично для меня является более серьёзным аргументом в пользу неправильно проведённого теста.
	Ответить | Правка | Наверх | Cообщить модератору

11. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+5 +/–
Сообщение от Аноним (11), 25-Мрт-24, 13:15
"тест с zip был запущен при холодном кэше, а остальные тесты при прогретом" Серьёзно? Это ведь эпичнейшая фейспальма!
Ответить | Правка | Наверх | Cообщить модератору

	16. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от Аноним (62), 25-Мрт-24, 13:27
	Чтобы дропнуть кэши надо записать 1 байт в специальный файл, очень сложно. Да и в чёрной-чёрной консоли, очень страшно! У нас тут дружелюбный паскаль. Но вообще, без указания версий и параметров это ни о чём. Поразительно низкое качество подачи материала, тот случай, когда со дна постучали.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+2 +/–
	Сообщение от тоже Аноним (ok), 25-Мрт-24, 13:44
	Это очень важный пункт эксперимента. Он наглядно демонстрирует, насколько стоит доверять всем остальным намерянным циферкам.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	30. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (-), 25-Мрт-24, 14:15
	Не на то смотришь. Если в намеренных данных не указаны ни доверительные интервалы, ни дисперсия, то не данные и были, кто-то просто нарисовал цифры от балды. Если есть, то следующий этап -- это исходные данные, на которых считались статистики или скрипт, который эти данные получает. Либо это есть, и вот тогда можно подумать над результатами статистики и как-то интерпретировать их, либо этого нет, тогда думать не о чем.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (44), 25-Мрт-24, 17:22
	Хорошо хоть что сами дали себе явную оценку в тестах. Хотя по результата и так ясно что авторы в полном неадеквате
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

12. Скрыто модератором	+/–
Сообщение от Аноним (12), 25-Мрт-24, 13:16
Безумству храбрых поём мы песню.
Ответить | Правка | Наверх | Cообщить модератору

15. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+2 +/–
Сообщение от Аноним (15), 25-Мрт-24, 13:24
Разве это не просто альтернативная реализация идеи https://www.sqlite.org/sqlar/doc/trunk/README.md ? > This repository contains sources for the "SQLite Archiver" program. This program (named "sqlar") operates much like "zip", except that the compressed archive it builds is stored in an SQLite database instead of a ZIP archive. Причём sqlar аж 2014 года.
Ответить | Правка | Наверх | Cообщить модератору

17. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–4 +/–
Сообщение от Аноним (18), 25-Мрт-24, 13:32
Скулайт итак мало для чего пригоден, так он теперь ещё и плохой архиватор.
Ответить | Правка | Наверх | Cообщить модератору

	19. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от Аноним (12), 25-Мрт-24, 13:35
	в докер надо засунуть, тогда будет норм
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Алексей (??), 25-Мрт-24, 14:32
	libsql
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от НяшМяш (ok), 25-Мрт-24, 14:44
	systemd-sqlited
	Ответить | Правка | Наверх | Cообщить модератору

20. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (20), 25-Мрт-24, 13:37
>предпринял попытку создания формата для архивирования файлов, построенного на базе библиотеки SQLite SQLite by design умеет исполнять произвольный код, поэтому даже просто открывать недоверенные SQLite-базы небезопасно.
Ответить | Правка | Наверх | Cообщить модератору

	52. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (53), 25-Мрт-24, 18:19
	Извините, но что это за uдuотская фича - исполнять код?? Это в смысле "брешь" в обработке файлов или это прямо специально реализованная фича?
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Прадед (?), 25-Мрт-24, 21:29
	Споткнулся и выполнил
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (84), 25-Мрт-24, 22:32
	Штатная фича - https://www.sqlite.org/lang_createview.html . VIEW - эта такая типа таблица, но когда из неё SELECT делаешь, то выполняется код, который при создании VIEW указали. Что-то вроде хранимой процедуры. Через них некоторый софт, который использует базы, можно эксплуатировать. Ещё в SQLite можно умышленно подредактировать контролируемым образом базу через редактирование служебных таблиц https://www.sqlite.org/schematab.html . Это можно прикрыть на уровне либы путём флагов ... но ведь скачанный с инета файл может быть сделан не твоей обмазанной флагами либой, а вообще форком. В общем ещё свежа память о том, как веб-страничкой с SQL-кодом, заточенным под эксплуатацию SQLite, Хром ломали (у него был API WebSQL на основе движка SQLite с навесными защитами).
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	77. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от tty0 (?), 25-Мрт-24, 23:27
	Вы меня пугаете. Программные хуки в SQLite выполняются софтом.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (84), 25-Мрт-24, 23:52
	Хромому они не помогли.
	Ответить | Правка | Наверх | Cообщить модератору

21. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (27), 25-Мрт-24, 13:40
>сжатию библиотекой libzstd Напоминаю - zip -это контейнер, и туда могут быть добавлены произвольные компрессоры. Просто большинство реализаций не смогут распаковать архивы с компрессией, отличными от zlib, lzma и lzma2.
Ответить | Правка | Наверх | Cообщить модератору

	24. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (27), 25-Мрт-24, 13:44
	даже PPMD очень не везде поддерживается. В качестве реализации рекомендую https://github.com/mcmilk/7-Zip-zstd
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от fuggy (ok), 25-Мрт-24, 14:10
	ppmd уже давно поддерживается в 7z. Или ты смешивает ppmd и zstd.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (33), 25-Мрт-24, 14:45
	в 7z - да, а вот во многих других реализациях помимо store и zlib в лучшем случае lzma2 поддерживается, а не полный комплект компрессоров. В питонью реализацию с помощью monkey-patchingа можно любой компрессор впрячь, и пакеты есть, но это всё же не приложение для конечного пользователя.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (62), 25-Мрт-24, 19:59
	По скорее бы завезли zstd в info-zip, уже много лет как zip поддерживает zstd  в стандарте. И zstd определённо предпочтительнее lzma по всем параметрам (а по многим и предпочтительнее deflate). А вот 7z что-то сдулся, теперь везде RAR и он не такой томозной и дефективный (даже больше линуксовых данных о файле поддерживает).
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (84), 25-Мрт-24, 21:53
	Мне плевать на "тормозной" до тех пор, пока замедление адекватно сжатию. У lzma2 оно адекватно, самое лучшее сжатие, что получал (на нужном наборе данных) - у brotli, просто бротли надо с песней компилировать и устанавливать на некоторых системах, а lzma из коробки идёт. zstd - это просто модно, юзаю его исключительно из-за наличия API для кастомного словаря в питоновском пакете (у lzma нет в пакете этого API). Но, как я уже сказал, хотя у brotli убрали вообще возможность юзать кастомный словарь в питоновском пакете, он жмёт лучше, чем zstd с шарингом словаря между записями. Поэтому, если есть возможность юзать бротли - то юзайте его.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от fuggy (ok), 25-Мрт-24, 22:55
	Чего не хватает в 7z так это больше фильтров для разных типов файла как в winrar. Сейчас он имеет фильтры только для исполняемых файлов и wav. Ещё фичей являются произвольные настраиваемые sfx модули. Куда можно встроить полноценный гуи или консольный установщик.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (62), 25-Мрт-24, 23:24
	Так у 7z тот же brunsli для картинок есть уже много лет. Как по мне, главная фича рар это коды коррекции, ну и стратегии кодирования выбирает более адекватно.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от fuggy (ok), 25-Мрт-24, 23:34
	Я хочу это чтобы было в стандартной поставке. Стратегии это по сути и есть препрецессор фильтры 7z для типа файла.
	Ответить | Правка | Наверх | Cообщить модератору

22. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (22), 25-Мрт-24, 13:41
А где сравнение с утилитой zstd?
Ответить | Правка | Наверх | Cообщить модератору

23. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (23), 25-Мрт-24, 13:42
Есть такой проект, Pigz называется, тотже gzip, но распаралленый. Быстро работает.
Ответить | Правка | Наверх | Cообщить модератору

	34. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от НяшМяш (ok), 25-Мрт-24, 14:49
	Плохо, что всё время забываешь -I pigz к tar подкидывать. Его уже надо бы по-умолчанию подхватывать, если установлен.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (36), 25-Мрт-24, 15:01
	Сделай его системным.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (40), 25-Мрт-24, 16:44
	pbzip2 тоже, но чуть лучше жмёт и при распаковке контрольную сумму проверяет.   mksqushfs тоже неплох с дефолтным lz4 сжатием.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

35. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
Сообщение от topin89 (ok), 25-Мрт-24, 14:56
> При сжатии каталога с 81 тысячей файлов, общим размером 1.25 ГБ Лучше пользоваться https://github.com/mhx/dwarfs. И сжимает мощно, и вместо распаковки можно просто смонтировать. Можно и lrzip или lrzip-next. Если бы в Pack был бы precomp или аналоги -- это уже было бы круто, и позволило бы сжать джипеги процентов на 20. Очень не хватает подобной штуки в потребительских архиваторах. А так вообще непонятно, чем именно оно лучше tar+zstd.
Ответить | Правка | Наверх | Cообщить модератору

	38. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (38), 25-Мрт-24, 15:21
	>read-only
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от Аноним (47), 25-Мрт-24, 17:54
	> А так вообще непонятно, чем именно оно лучше tar+zstd. Прежде всего тем, что может вытащить ЛЮБОЙ файл за минимальное время.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	51. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (44), 25-Мрт-24, 18:11
	Не, нужно так писать > Прежде всего тем, что МОЖЕТ вытащить ЛЮБОЙ файл за МИНИМАЛЬНОЕ время.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от непонятка (?), 27-Мрт-24, 06:26
	А этот dwarfs в качестве хранилки библиотеки сойдет?
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	115. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от topin89 (ok), 17-Апр-24, 13:04
	> А этот dwarfs в качестве хранилки библиотеки сойдет? В целом да. Но если данные сами по себе плохо сжимаются, то проще как есть в папках хранить. Всё-таки это read-only fs, докидывать новые файлики будет трудно
	Ответить | Правка | Наверх | Cообщить модератору

39. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
Сообщение от Аноним (-), 25-Мрт-24, 16:44
Давно ищу архиватор/способ чтоб в архиве сохранялась дата создания(через stat это Birth) и изменения файлов(через stat это Modify), дописывать в имена файлов не вариант. В "окошках" все популярные форматы это умеют, а в более продвинутой ОС это не работает. Да ну не может быть подумал я .. какая же это была ошибка, ну вот нет такого. Долгие поиски и.. последняя надежда на 7z после выкатывания исходников для сборки от автора, но он продолжил стандартную "подлянку" с "Change" вместо "Birth", автору писал "не баг, а фича". Я пытался разобраться в исходниках и сделать нормальное поведение, как заявлено в документации, нуу и не смог.. Если кто-то знает где это правится, поделитесь пожалуйста, можно патчем. Или может другой способ какой рабочий.
Ответить | Правка | Наверх | Cообщить модератору

	46. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (47), 25-Мрт-24, 17:53
	Если сам формат файла хранит только ОДНУ дату, вряд ли ты сможешь туда засунуть вторую! (это так, мысли вслух) Спроси автора, может он идею какую подкинет (писать дату в комменты или что-то подобное).
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (48), 25-Мрт-24, 18:00
	> а в более продвинутой ОС это не работает. Да ну не может быть подумал > я .. какая же это была ошибка, ну вот нет такого. Это в какой именно "более продвинутой"? А то у лапчатых например Birth был долго "нинужна!" (ext2/3/4) - оттуда и отсутствие у многих утилит вменяемой поддержки.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	50. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (48), 25-Мрт-24, 18:06
	>> а в более продвинутой ОС это не работает. Да ну не может быть подумал >> я .. какая же это была ошибка, ну вот нет такого. > (ext2/3/4) Тьфу, 4 там лишняя. Но пингвинячий stat() таки традиционно не поддерживает b_time.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (62), 25-Мрт-24, 19:54
	Не так и давно, поддержку birth иноды (не столь и полезная для архивации информация на самом деле) в ядро добавили только несколько лет назад и только около года назад её добавили в glibc и следом в dolphin (с тех пор я её использую постоянно). Я использую расширенные аттрибуты для сохранения даты создания файла (и хеша, удобно после распаковки архива знать что это был за архив и когда модифицирован в оригинале, файлы не меняются, поэтому это и есть время создания плюс время записи), чтобы получить что-то вроде того, что есть на macos. Но я вижу, что многое надо доработать в файловом менеджере, например, чтобы он не удалял расширенные аттрибуты при копировании/перемещении файла. >7z Oн вообще не сохраняет никакие линуксовые параметры файла, возлагать какие-либо надежды на грязную вендузятскую поделку не стоит. Лучше стоит обратить внимание на tar, и в частности индексированный tar позволяет получить быстрый произвольный доступ к сжатым данным, чего не может тот же 7z. А по степени сжатия lrzip-zpaq натравленный на тарбол, в большинстве случаев значительно обходит 7z, и, кроме того, в режиме lrzip-lzma или даже lrzip-gzip он его обходит, поскольку полноценно дедуплицирует данные. Правда, его вряд ли получится индексировать, но тут уж стоит выбирать в зависимости от характера данных.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	66. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–1 +/–
	Сообщение от Аноним (66), 25-Мрт-24, 21:49
	>>7z >Oн вообще не сохраняет никакие линуксовые параметры файла, возлагать какие-либо надежды Неужели вы до сих пор путаете архиватор с компрессором? Использую для архивации *.tar.7z - что я делаю не так?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (70), 25-Мрт-24, 22:09
	>> и в частности индексированный tar позволяет получить быстрый произвольный доступ к сжатым данным, > Использую для архивации *.tar.7z - что я делаю не так? Обрати внимание на "быстрый произвольный доступ к сжатым данным".
	Ответить | Правка | Наверх | Cообщить модератору

41. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+2 +/–
Сообщение от Аноним (42), 25-Мрт-24, 17:09
Я тут уже лет 10 пишу, что с появлением твердотельников будущее за файловыми системами на основе хешей и БД.
Ответить | Правка | Наверх | Cообщить модератору

45. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (47), 25-Мрт-24, 17:51
> чтению данных, сжатию библиотекой libzstd и выполнению SQL-операций по добавлению сжатых данных в файл с БД SQLite Это имеет смысл только на конкретных юзкейсах "имеем один большой архив и периодически обновляем там некоторые файлы". Для простых бэкапов (где критична степень сжатия) нужен сжимальщик, который учитывает ВЕСЬ контент - типа 7z (solid архивы).
Ответить | Правка | Наверх | Cообщить модератору

49. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (49), 25-Мрт-24, 18:02
Оверинженеринг
Ответить | Правка | Наверх | Cообщить модератору

	58. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от Аноним (58), 25-Мрт-24, 19:57
	Прелестный эксперимент. Чтоб подумать над результатом. :)
	Ответить | Правка | Наверх | Cообщить модератору

55. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+8 +/–
Сообщение от O (?), 25-Мрт-24, 18:56
Здравствуйте, I am the author of Pack, and I am happy to see you all interested in Pack. I am sorry for writing in English; my understanding of Russian is limited to that Здравствуйте. I try to answer most of the comments here, but if you have any further questions or comments, let me know or email me (you can find it in the linked post). Warm or Cold:     On the linked post (https://pack.ac/note/pack), there is a line noting the test condition: "All corresponding official programs were used in an out-of-the-box configuration at the time of writing in a warm state."     Please note that for ZIP, the official tool is WinZip and I tried the test many times to find the best warm time and remove any file system and disk interference.     As noted in the post, you should test it for yourself. The numbers were not as "Look, others are bad". They are great; my point was, "Look what we can do if we update our design and code"     Random access (extracting one):     You can do that with Pack:     `pack -i ./test.pack --include=/a/file.txt`     or a couple files and folders at once:     `pack -i ./test.pack --include=/a/file.txt --include=/a/folder/`     Use `--list` to get a list of all files:     `pack -i ./test.pack --list`     Such random access using `--include` is very fast. As an example, if I want to extract just a .c file from the whole codebase of Linux, it can be done (on my machine) in 30 ms, compared to near 500 ms for WinRAR or 2500 ms for tar.gz. And it will just worsen when you count encryption. For now, Pack encryption is not public, but when it is, you can access a file in a locked Pack file in a matter of milliseconds rather than seconds. Is it a compressed database?:     No. It is a container for files and raw data. Projects like sqlite-zstd are for any database for your projects. They are not made for files. sqlar:     Pack is a new format. sqlar inspired me to create Pack as a new improved solution.     Here is the latest sqlar result on Linux source code on the same test machine in warm state:     sqlar: 268 MB, 30.5 s     Pack: 194 MB, 1.3 s SQLite security:     It is one, if not the most secure, library out there. It is very hard to crack it, and it will not allow running any harmful code on a machine. It is used in almost anything with a computer, partially because of its security and reliability. File system:     Noted projects like dwarfs are file systems.     It is read-only; Pack is not. Update and delete are not just public yet, as I wanted people to get the taste first.     It is clearly focused on archiving, rather than Pack wanting to be a container option for people who want to pack some files/data and store or send them with no privacy dangers. Big files instead of many small files:     Reading many files (81K in this test) is way slower than reading just one big file. For bigger files, Pack is much faster. Here is a link to some results from a kind contributor: https://forum.lazarus.freepascal.org/index.php/topic,66281.msg507177.html#msg507177     (Too long to post here) tar.zst:     As requested, here are some numbers on tar.zst of Linux source code (the test subject in the note):     tar.zst: 196 MB, 5420 ms (using out-of-the-box config and -T0 to let it use all the cores. Without it, it would be, 7570 ms. And it is done in two steps: first creating tar and then compression.)     Pack: 194 MB, 1300 ms Slightly smaller size, and more than 4X faster. (Again, it is on my machine; you need to try it for yourself.)     Honestly, ZSTD is great. Tar is slowing it down (because of its old design and being one thread).     Pack does all the steps (read, check, compress, and write) together, and this weaving helped achieve this speed and random access. Rate of compression:     7-Zip and other similar tools are focused on compression rate. Pack is on another chart, which is why I proposed CompressedSpeed [2]. The speed of getting to compression needs to be accounted for. You can store anything on an atom if you try hard enough, but hard work takes time. Deduplication step may get added, but in Hard Press [3].     RAR compression speed is great too. Many times, it can do better than Pack. My argument is that does it worth the wait? After all, if you can use Pack for those cases too,. Hard Press [3] creates a more compressed pack for cases of pack once, unpack many.     [1] CompressedSpeed = (InputSize / OutputSize) * (InputSize / Speed). Materialized compression speed.     [2] You can choose --press=hard to ask for better compression. Even with Hard Press, Pack does not try to eat your hardware just to get a little more; it goes the optimized way I described. User experience:     Pack value comes from user experience, and speed is being one. I was not following the best speed or compression; I wanted an instantaneous feeling for most files. I wanted a better API, an easier CLI, improved OS integration (soon), and more safety and reliability. On a final note, I suggest trying Pack for yourself and on your machine. I will be glad to hear more about your experience. Thank you
Ответить | Правка | Наверх | Cообщить модератору

	63. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (84), 25-Мрт-24, 21:23
	>SQLite security: >It is one, if not the most secure, library out there. It is very hard to crack it, and it will not allow running any harmful code on a machine. It is used in almost anything with a computer, partially because of its security and reliability. https://www.blackhat.com/docs/us-17/wednesday/us-17-Feng-Man... Yes, I have read https://www.sqlite.org/security.html , but * I still don't believe it is possible to make SQLite secure as an exchange format, there is a long trail of vulnrs in it allowing to achieve an RCE triggered by just opening a maliciously crafted database file and SELECTing from it. * IMHO quality metrics for a good RDBMS are different from the ones of a good archiver. Everything is a tradeoff and there is ain't no such a thing as free lunch. RDBMS are information retrieval tools, they require good performance on wide ranges of queries and are usually operated on trusted data, so sacrificing some amount of security for performance is a tradeoff good RDBMS have to make. Archivers also need to be performant, but they are almost always operated on files from untrusted sources (downloaded from the Internet from random web pages) and so first of all they need to be secure, and then queries for them are pretty limited (basically it is a key-value storage), so a good archiver should optimize storage format for that purpose. I know that when one has a hammer, all problems look like a nail, but let's drive nails with hammers, not with microscopes ("drive nails with microscopes" is a Russian idiom, I hope you get its meaning).
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (84), 25-Мрт-24, 21:32
	And forgot to add: * For the purpose of this paragraph let's assumme that SQLite when built with maximum hardening is secure ... Even if you use maximum source-level hardening options of SQLite, it would limit your software to 2 options: statically linking the SQLite lib with thisenoptions, or dynamically linking an additional variant of SQLite lib living in a separate package. Some distro maintainers can forget about this security measure and just link the usual distrowise SQLite lib optimized for performance and special tasks like schema manipulation ... creating this way a vulnerability. So mere using SQLite for the task it is unsuitable for introduces a weak point.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от O (?), 26-Мрт-24, 00:55
	All are an will be statically linked. They are not considered a shared library to the program, but part of the source.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–3 +/–
	Сообщение от Аноним (84), 26-Мрт-24, 02:21
	Noone sane uses statically-linked libs and sane distros would never accept anything using statically linked libs. It is unmaintainable shit. If a yet another critical RCE vulnr is found in your precious SQLite, then the lib in the distro will be upgraded, but your archiver (needed by nobody sane and kept only to make a check mark that they have it in the repo, if it got enough adoption) with statically linked SQLite will stay vulnerable. We have enough pain in the ass with Python's pickle, which should be considered a backdoor. If your archiver gets any adoption, there will be a yet another backdoor. Yes, I consider your archive format as a backdoor, and the attempt to forcibly promote it, to the point you are tracking mentions of it on websites in foreign languages, as an attempt to promote a hard-to-remove (if it got adoption and there would be enough archives of your format with valuable unique content in the Internet, so users would have no other option, but to either use SQLite and tolerate the risk, or create an own impl of SQLite specifucally designed to deal with malicious databases securely) backdoor.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (62), 26-Мрт-24, 10:43
	Ты просто не пользовался скулайтом, он примерно всегда бандлится. Или не заметил. Ну и все мейнтейнеры жрут, что им навалят разрабы, странный аргумент. Потому что шляпа вроде ffmpeg или libvpx регулярно ломает совместимость, но узнаешь ты об этом только когда пользователи начнут ныть (подход компилируется значит работает очень популярный у мейнтенеров). Или другой пример именно статически линкуемого компонента неизвестной версии это zlib.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (89), 26-Мрт-24, 13:07
	>Ты просто не пользовался скулайтом, он примерно всегда бандлится У неадекватов всё подряд бандлится, причём с обоснованием уровня "а вот я тут главный, хочу так, и ниипёт". Некоторые доходят до того, чтш используют Rust или поставляют свои программы в формате Snap или Docker-контейнеров. zlib и sqlite вообще отличаются довольно стабильным API и очень широко используются, я не помню, чтобы хоть раз какой-либо софт сломался из-за этих либ, прилинкованных динамически. Вот пример адекватного пакетирования https://packages.debian.org/sid/python3.12-minimal , https://packages.debian.org/sid/libzip4t64 , https://packages.debian.org/sid/libarchive13t64 , https://packages.debian.org/ru/sid/libxft-dev , https://packages.debian.org/buster/libsvn-dev (остальное найдёшь сам, меня забанили в Гугле. zlib1g AND -inurl:zlib1g AND -inurl:lib32z1 AND -inurl:lib64z1 AND -inurl:search AND -inurl:search_contents AND -inurl:zlib AND site:packages.debian.org) - зависит от https://packages.debian.org/sid/zlib1g https://packages.debian.org/sid/libpython3.12-stdlib - зависит от https://packages.debian.org/sid/libsqlite3-0 А свои сказки про то, что всегда бандлится ... я уже сказал, бандлится только у неадекватов, которым лень разобраться в работе CMake, поэтому у которых всё на git-подмодулях или вообще просто скопировано в дерево исходников.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (62), 26-Мрт-24, 13:24
	Дело не в этом. Лучше смотри на это с позиции когда мейнтенеры не будут возиться с разбандливанием и разгребанием багов в каждой поделке (а они там будут). Если говорить о скулите, то дистрибутивная версия может быть собрана без secure-delete (потому что это угрожает производительности), а та, что поставляется, например, с браузером, компилируется с этим флагом. Версии, поставляемые с браузером,  во многих случаях будут более новые, либо с применёнными (иными) патчами. В целом, особенно актуальны вопросы совместимости для программ на плюсах, сишные в значительной мере совместимы. Но всё равно нельзя взять и подсунуть произвольную версию и только разрабы знают какая подходит и почему, не мейнтейнеры. Куда чаще проблема не в том, что разрабы не разбираются, а в том, что мейнтейнеры разбираются недостаточно хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (96), 26-Мрт-24, 14:40
	Да, есть такая проблема. И это проблема в том числе самого SQLite. Слишком многое там конфигурируется во время компиляции флагами компиляции. Потому что нефиг на Си писать. Писать надо было на плюсах и юзать шаблоны, создавая где очень критично к производительности 2 версии кода, и не через макросы, а через ifы/switchи, где в каждом варианте все ветви кроме гдной будут выоптимизированы компилятором. Ещё проблем добавляет модель разработки SQLite - "мы не будем брать ваши патчи, мы возьмём только заказ на работу и гонорар за его исполнение". Костыльный вариант решения я вижу таким — запакетировать несколько бинарных вариантов либы под распространённые use case и линковать приложения к нужному варианту. >Но всё равно нельзя взять и подсунуть произвольную версию и только разрабы знают какая подходит Поэтому в программы и либы приходится пихать рантайм-диагностику, анализирующую флаги сборки и фичи, где целесообразно - включающую fallbackи и генерирующую рекомендации о том, какие флаги нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от O (?), 26-Мрт-24, 13:12
	Hey I am sorry that you think like that. Not much tracking, rather shared with me on the Lazarus forum (IDE I sued for developing Pack), and I thought clearing some points may help some others. I can explain more and correct your mistaken statements, but because of your way of talking, I think it won't help.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	94. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (89), 26-Мрт-24, 13:30
	I can give you a simple advice that will fix all issues in your format: just admit that it was an extremily bad idea to promote it as an archive format and put noticable warnings about that everywhere: on official webpages, in git repo, etc. For the uses that don't promote it as an archive format, but as a key-value store for a local use only in a pretty trusted setup ... there are plenty of solutions, and no hype around them.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (84), 26-Мрт-24, 02:33
	Some moar things I forgot to add: * If this format gets adoption, insecure implementations in other languages will emerge. Just because it is easier and more correct to use the systemwide- or standard-lib-shipped SQLite lib rather than a custom-built one. For example a Python impl will just use the one available via import sqlite3, and it is the systemwide libsqlite3.so optimized fir speed and versatility. * SQLite database can contain garbage, that can contain sensitive information. It can be cleaned though, but vacuuming takes a twice as large space as the file is, because for fail-recovery purposes it makes a copy first, and then clears the original file. * SQLite databases can produce additional files alongside with database files. Journals and wrute-ahead logs. Deleting such files before they are merged into a main database file corrupts that database.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	92. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от O (?), 26-Мрт-24, 13:24
	Thank you for the interest. - As long as they use the official work, it will be securely checked and verified. - If anyone attempts to rewrite, they need to take security seriously too. Just as different implementations of JPEG have different security flaws that need to be taken care of,. And a big reason most will use the official. - One good point about Pack is that if they use SQLite, almost all will be secure from bad memory access problems, as SQLite is much more tested and reliable. - SQLite has secure delete too, which does not take much extra time: https://www.sqlite.org/pragma.html#pragma_secure_delete - Your point about updating, and while doing that, those files are locked by OS. No one can delete them unless they force it.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (98), 26-Мрт-24, 15:58
	>SQLite has secure delete too, which does not take much extra time: https://www.sqlite.org/pragma.html#pragma_secure_delete The fast variant doesn't guarantee cleanup. The slow one results in additional I/O = SSD wear. And you position your archiver as a faster alternative to zip, and additional cleanup will make it less fast. >If anyone attempts to rewrite, they need to take security seriously too Let's say it clear — IRL security of software is not a problem of software author, it is a problem of software user. Most of software have licenses, and every sane license disclaim any liabilty. For software not having licences you get no warranty either. Software is distributed AS IS and its users are liable themselves that they have to use software written by assholes. Ones who is not OK with that have to create an own "Juche"-software, in the extreme case of total so-called "supply-chain security" - the whole stack: own research facilities, own foundries, own hardware, own microcode, own firmware, own OS, own libraries, own applications, own Internet to use their Juche-stack with (because Juche-stack will never pass Web Environment Integrity check), own everything :), and hold liability themselves and blame themselves solely. This will never happen in real world. You know it (don't pretend you don't!), because everyone, including you, uses insecure (and often - intentionally backdoored) software and hardware created by assholes. In real worlde cannot expect that all the implementers will implement software "securely" when implementing it "securely" faces serious challenges. In this case it is very tempting to just use an SQLite lib from the distro/programming language and add a few code above it. Using another SQLite lib is not easy ... for example in the case of Python a) one needs a dependency, `apws` package b) since it is implemented in C, it has to be built, which is a big issue in Windows hosts c) one needs a hardened SQLite lib d) it also has to be built e) one needs a way to plug that hardened SQLite lib into the programming language lib ... surprise, there is no such a feature in `apws`, its author's build scripts link it to hardcoded source-level included SQLite. There are ways to link it to external `libsqlite3.so`, but it seems they are jntentionally made pain in the ass. So one has to implement the feature in `apws` to load a certain shared SQLite lib per connection, persuade the maintainer of `apws` it is needed, upstream it to `apws`, backport that version of `apws` to all legacy versions of Python needed (and some of them are needed because assholes in PSF have decuded to drop certain versions of OSes, so to have a new version of Python one has either to maintain an own fork of it or buy a new PC with a license to a new version of the OS, and given that that OS was created by assholes, that version of the OS should never be used at all, so one has to use a hacky workaround to install a new version of Python onto a dropped version of OS that can break any time), persuade a user that he needs a tool with a dependency... So in real world the only viable tradeoff a dev has to make is just to use `sqlite3`. And the only viable tradeoff users (including the dev himself) have to make is just use insecure shitware written by assholes in order to just not to create own software and not to withstand the pressures to create a yet another piece of shit, and pray that the files they have to open are not exploits, instead of trying to live without those files. So people will just have to use insecure impls made by assholes. Real world issues caused by the format proposed by you strongly outweight all the benefits your format claims to provide. >One good point about Pack is that if they use SQLite, almost all will be secure from bad memory access problems, as SQLite is much more tested and reliable. Just use Kaitai (optionally with Rust/Python/Java/C# target) for parsing of properly designed binary formats and you should be pretty safe from insecure memory access. >Your point about updating, and while doing that, those files are locked by OS. No one can delete them unless they force it. Mandatory locks have to be explicitly be enabled in kernel during compilation. Kernels in distros are compiled without mandatory locks. Also, I have seen a lot of times additional files being kept after normal process termination. I have to open bases with `sqlite3` CLI tool to get rid of the unneeded files in those cases (usually backup). And if a process crashes mid-operation, they are always present. >Just as different implementations of JPEG have different security flaws that need to be taken care of,. And a big reason most will use the official. JPEG is not based on misusing preexisting widely-available lib that is insecure for that use case. JPEG doesn't create such drastic incentives to create ihsecure shit. If you want to create a new archive format, just leave SQLite alone and design an own format and own lib, not based on SQLite, not using its source code, but written from scratch, using memory-safe subset of languages, with security-first design, using some ideas from fast databases.
	Ответить | Правка | Наверх | Cообщить модератору

67. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от BrainFucker (ok), 25-Мрт-24, 21:52
Предпочитаю squashfs для архивирования. У него встроенное сжатие, но главное можно примонтировать и читать файлы с произвольным доступом без необходимости распаковывать весь архив.
Ответить | Правка | Наверх | Cообщить модератору

	100. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от Аноним (100), 26-Мрт-24, 18:13
	Рекомендую dwarfs, он лучше
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
	Сообщение от BrainFucker (ok), 26-Мрт-24, 20:33
	> Рекомендую dwarfs, он лучше Ок, подождём лет десять, как появится в репах дистрибутивов и если проект не будет заброшен, можно будет попробовать.
	Ответить | Правка | Наверх | Cообщить модератору

88. "Эксперимент с использованием SQLite в качестве контейнера дл..."	–1 +/–
Сообщение от DZgas (?), 26-Мрт-24, 11:39
👍 прект наебалго, разница скорости между Ним и 7zip zstd примрено 15% по скорости, то есть, проект pack не создаёт ни хэша файла, ни фаловой иерархии внутри. И поэтому на примерно 15% быстрее
Ответить | Правка | Наверх | Cообщить модератору

	91. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+1 +/–
	Сообщение от O (?), 26-Мрт-24, 13:17
	File hierarchy is implemented using recursive ID. In Item table, every Item gets linked to its parent by Parent field. On unpacking, they will be queried and verified. The hash of any compressed data is already stored and verified at the unpack step. It does not have an extra field, as it is stored together with the content. Each file or piece of data gets separated and/or joined with others as content, then compressed if seen as beneficial. Zstandard (the internal compression algorithm) uses xxHash together with a header to verify decompression. On unpacking, all needed Items (files or folders) get queried and checked, followed by all the ItemContents and related Contents. Each gets verified to be the correct size to prevent invalid memory access, and if decompression is needed, they will be double verified with their corresponding hash.
	Ответить | Правка | Наверх | Cообщить модератору

103. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от Аноним (103), 27-Мрт-24, 06:15
В 7z мне не хватает CRC.
Ответить | Правка | Наверх | Cообщить модератору

107. "Эксперимент с использованием SQLite в качестве контейнера дл..."	+/–
Сообщение от mumu (ok), 28-Мрт-24, 16:01
некорректный дизайн теста. паскаль. no comments
Ответить | Правка | Наверх | Cообщить модератору

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

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