Библиотека Flibusta (только FB2) на 01.12.2024 (645479 книг) (локальная коллекция, пополняемая ежемесячно) + MyHomeLib + inpx

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

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

В принципе, как я уже согласился с vlbeznosov, никто никому ничего не должен и никто никого не заставляет. Просто новичкам надо бы знать про это, так сказать для сведения, а заодно о всяких различиях тех или иных ПОЛНЫХ версий библиотек.

Интересные цифири получаются. Взяты первый два архива:

1651M fb2-000024-030559.zip - оригинальный
1065M fb2-000024-030559.zip.repack - перепакованый после удаления удалённых книг
(выгода почти 600 мегабайт)
15M fb2-000024-030559.zip.xdelta - патч для xdelta который позволяет сделать из оригинального перепакованый архив - вообще копейки весит

1649M fb2-030560-060423.zip - оригинальный
1104M fb2-030560-060423.zip.repack - перепакованый после удаления удалённых книг
(выгода 545 мегабайт)
14M fb2-030560-060423.zip.xdelta - патч для xdelta который позволяет сделать из оригинального перепакованый архив - вообще копейки весит

Получается что только на первых двух архивах уже экономия 1G, а патчи для xdelta скачивать по трафику вообще не напряжно нисколько. Т.е. впоследствие можно делать repack архивы с новыми xdelta патчами, которые будут весить сущую ерунду - ничего перекачивать заново в огромном размере - как предполагалось - вовсе не нужно!

Вот именно, что первый. Наверняка, удалённых больше всего именно в них. А вот в последних, скорее всего, и 10% не наберётся... Ну и я про то же. Надо ещё не забывать того, что зипуете вы своей программой со своими параметрами, которые тоже могут сильно повлиять на результат. А вот это довольно глупо. Т.к. всё в мире идёт к поддержке именно UTF в огромном кол-ве устройств, и сводить всё к устаревшей чисто виндовой кодировке. К тому же вы забыли про один из основных принципов сжатия - заменять повторяющиеся последовательности короткими и вовсе не относящимися к кодировкам. Текст - в основном именно "повторяющиеся последовательности", потому так хорошо и жмётся. Так что "аааааааааа" сожмётся во что-то типа 10"а", при этом размер самого "а" несущественен. Да - для многих устройств, не понимающих cp1251, без ручной перекодировки - нечитабельны. А для людей "с руками" проблем вообще мало. Только вот книги читают не только они.

И да, надо не забывать, что прежде всего такие объёмы сделаны имеенно для торрентов, а для них сохранение содержания старых файлов - просто необходимо. А про "новичков" - так новички они только первый раз, а потом тоже докачивают...

Друзья, предлагаю прекратить дискуссию, поскольку позиции сторон уже ясны и смысла в дальнейшем обсуждении лично я не вижу. Вообще, на мой взгляд, при нынешних скоростях доступа в инет и стоимости хранения одного гигабайта информации вопрос хранения условно лишних файлов актуален далеко не для всех. Кроме того, подумайте вот над чем: в этой библиотеке порядка 250000 книг. Из них как минимум 200000 вам не понадобятся никогда, ибо человек, активно читая всю жизнь, может прочесть около 5000 книг. Если не учитывать скорочтение, конечно. Даже в этом случае больше 50000 книг всё равно не прочитать. Так стоит ли заводить дискуссию из-за удалённых книг, если подавляющая часть книг всё равно лежит мёртвым грузом?

Это, конечно, легко приходящий в голову аргумент. Однако, он опровергается тем, что "какую именно книгу из 250000 мне захочется прочитать в следующий момент" - совершенно неоднозначно. Если же считать, что я её в любой момент могу скачать из сети, то вообще скачивание себе сетевых библиотек (да как и торренты вообще) совершенно теряет смысл. Впрочем, по мере развития сетей и правовых отношений (чтобы книги были доступны легально либо за крайне низкую плату с везде развитыми системами мгновенной оплаты) - возможно так и будет. Любую информацию на винчестерах никто хранить не будет, всё будем качать из "Центрального информатория". Который, впрочем, прямо на глазах формируется "облачными технологиями". Хотя, человек - существо с особенностями. Как-то ещё хочется, чтобы всё было тут, рядом, в своём, собственном, кармашке

Я ничего не забыл. Я просто проверил на практике. Архив из одних и тех же файлов в UTF-8 и перекодированных в cp1251 отличается на 200 мегабайт при размере в 1G - как бы выйгрыш 1/5 что не так мало Вы тоже не забывайте, что zip довольно посредственный архиватор Увы, но ещё очень и очень много людей в провинциях сидят на плохих каналах. Вот тут вы полжалуй, правы. Надо оформлять всё и выкладывать как уже свою собственную альтернативную раздачу, но не факт что дойдут руки. Как в общем-то я уже писал выше - всё это скорее для свединия.

Взяли бы да выложили SQL-запрос и шелл-скрипт, описали как этим пользоваться , может быть кто и заинтерисовался. Да и спасибо Вам сказал.

Если кто-то уже заинтересовался, выложу. Подождите пару дней - всё осталось на работе. Как только туда попаду - выложу, мне не жалко

дъякую

Описываю, что надо делать по шагам. Сам работаю в Linux поэтому просто описываю что надо, скрипты для Linux будут в конце, а пользователи Windows смогут написать пользуясь пошаговой инструкцией.

1. Значит так. Берём выгрузку базы с Флибусты:
http://www.flibusta.net/sql/
нужен всего-то один файл lib.libbook.sql.gz

2. Подымаем у себя локально MySQL. Пользователям linux он доступен сразу после установки пакета mysql-server, пользователи Windows могут воспользоваться проектом Denwer (http://www.denwer.ru/), там же есть руководство по установке.

3. Запускаем утилиту командной строки mysql:

4. Создаём базу данных с любым названием, например flibusta
CREATE DATABASE flibusta;

5. Создаём пользователя для подключения к БД с именем flibusta паролем 123qwe
GRANT ALL ON flibusta.* TO flibusta@localhost IDENTIFIED BY '123qwe';
FLUSH PRIVILEGES;
\q

6. Загружаем полученный с флибусты файл. (Пользователям windows понадобится утилита для его распаковки gzip):
gzip -d lib.libbook.sql.gz
получится файл без расширения .gz (только .sql)
далее:
mysql -u flibusta -p flibusta <lib.libbook.sql
спросит пароль: введёте 123qwe

7. Получаем список номеров удалённых книг:
echo "SELECT BookID FROM libbook WHERE Deleted=1" | mysql -u flibusta -p flibusta >1.txt
спросит пароль: введёте 123qwe
теперь у вас в файле 1.txt будут номера всех удалённых книг

8. Берём любой архив, например fb2-000024-030559.zip. Распаковываем его в какой-либо отдельный каталог:
unzip fb2-000024-030559.zip

9. Теперь выполняем bash-скрипт (для Linux):
cat 1.txt|while read a; do; rm -f "${a}.fb2"; echo "${a}.fb2"; done
Поясняю, что оно делает для пользователей Windows. Тупо читает по строчке из файла 1.txt затем удаляет тот файл, у которого имя совпадает с "номер.fb2" ну и выводит имя обрабатываемого файла. Ключ -f нужен, чтобы rm не спрашивала каждый раз удалять или нет.

10. После окончания работы скрипта нужно запаковать архив обратно:
zip fb2-000024-030559.zip *.fb2
Получаем архив уже намного меньшего размера, который содержит только неудалённые книги.

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

Замечание 1: Обрабатываются только fb2-файлы. С остальными форматами пока не занимался, там несколько сложнее - имена файлов хранятся в отдельной таблице.

Замечание 2: Обратите внимание, что то, что вы скачаете с Флибусты - это состояние каталога на сегодня! А от какого числа скачены файлы архивов - вам виднее. Если непонятно, поясняю, вы можете удалить такие книги, которые в ваших архивах ещё не обновились, потому что вы не загрузили все файлы с книгами на число соответствующее скаченному каталогу книг.

Скрипт для обработки всей пачки fb2*.zip архивов. Обратите внимание, новые архивы создаются в подкаталоге 1 того каталога, где будет запущен скрипт, т.е. старые архивы не трогаются - либо озаботьтесь местом, либо поправьте скрипт, чтобы перезаписывал старые архивы:

#!/bin/bash

mkdir -p 1
for i in fb2-*.zip
do
cd 1
echo "$i"
unzip "../$i"
cat ../1.txt|while read a
do
rm -f "${a}.fb2"
echo "${a}.fb2"
done
zip "$i" *.fb2
rm -f *.fb2
cd ..
done
скрипт написан несколько неэффективно - проходит каждый раз по ВСЕМ номерам, а не только по тем, что были в архиве - лень было писать анализ, кому надо - сделаете.

vv1974 После всех этих танцев с бубном пользователю ещё нужно создать INPX для своей почищенной коллекции. Чистку архивов от "удаленных" книг может прекрасно сделать и сама MyHomeLib (а также LibRusLib) методом отправки на устройство. Во вкладке Поиск в окне Папка (архив) вписываем имя нужного архива. В окне Тип можно ничего не писать (или написать fb2). Ставим галочку Скрывать удаленные. Если нужен только русский язык книг коллекции, то в окне Язык нужно выбрать ru. Жмем Применить. Ждем в большом окне список. В окне со списком книг жмем Ctrl+A (около всех книг появятся галочки) и Ctrl+D (начнется отправка книг на устройство). Предварительно в Настройках нужно выбрать папку на устройстве, Формат записи .fb2 Формат имени Файл %id Следующий этап - запаковать файлы в архив. После чистки и упаковки всех архивов с помощью программы lib2inpx создать новый INPX для свой коллекции. С этого момента про обновления можете забыть (докачивать недостающие архивы нужно обязательно и проделать вышеописанную процедуру с новым архивом). Все придется делать самому.

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

vv1974

1. Что есть дельта файлы? Файлы малого размера, указывающие, что изменилось в изначальном файле? Если не так, то пункт 1 пропускайте. Допустим есть базовый набор файлов, по месяцам, общим количеством N.Неважно, существующий ли это набор или вы заставите всех перекачать, изначально перепаковав. Назовем его 0. Через месяц мы (мы? точно не Вы и не я) бодро формируем к этому набору 1..N ваших дельт. Назовем их delta0 - в них будут изменения относительно набора 0. Все скачали, все довольны, все разобрались, что с этими дельтами делать(ага, щас - но пропустим). Прошел еще месяц. Нужно делать еще дельты. Относительно какого месяца вы будете их делать? Относительно изначального (новые delta0) или первого (delta1)?

2.Когда еще не было этой раздачи и раздача Кайзера заморозилась, для значительного числа людей (имхо, более половины), было проблемой скачать два файла - месячный и inpx. Просто два файла в один каталог - что было бы идентично обновлению полной раздачи. Но Два(!) файла - и уже проблема. Какой процент людей будет разбираться с механизмом дельт?

upd. (утром торопился, не дописал) Кроме противоречия, описанного в п.1., у идеи с дельтами есть еще один критический недостаток. Пользователь, скачавший дельты и перепаковавший свои архивы, автоматически уходит с раздачи этих архивов(они перестают соответствовать). Некому будет раздавать новым пользователям.

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

Я писал выше. Есть в Linux утилита xdelta которая умеет по двум бинарным файлам построить файл .delta с помощью которого из 1-го бинарника можно получить 2-й. Как я опять-таки уже писал, при разнице оригинального и перепакованного архива в 500 метров, delta файл имеет размер всего 15 метров Очевидно что надо вести два набора дельт. Один набор от оригинального архива для вновь скачавших, другой набор от предыдущих дельт. Если всё оставить на уровне напильника - малый. Если же предоставить средство автоматического применения к архиву дельт, чтобы осталось только скачать и нажать - многие. Пользователь скачавший дельты, дельты же и будет раздавать.

deleted