Citadel - Calibre-compatible book management tool

[ownedbycats]

Not very impressed.

I imagine it'd have a lot of fun with my library with its dozen or so composite columns.

[DNSB]

Just to satisfy my curiosity, I downloaded the citadel_0.1.0_amd64.deb and citadel_0.1.0_amd64.AppImage files.

I installed the .deb file on a Debian 12.4 virtual machine where calibre 7.4 and a library of ~2500 books was installed. The VM has 16GB of RAM, 8 cores and a 64GB HD. The host system has an i9 CPU with 64GB of RAM, a 1TB PCI4 NVME drive. In theory, the VM should be using the performance cores and not the efficiency cores.

Citadel may have started up a trifle faster but not enough for me to notice. I was not that happy with the GUI but then I'm used to calibre's GUI. OTOH, after 15 minutes, my library was corrupted and I ended up reverting to the snapshot of the VM before the install.

I then tried the AppImage version on the restored from snapshot VM. I couldn't see any differences and again, after using Citadel for a while, my library was corrupted. Reverted to the snapshot and will not be trying Citadel again in the next while.

It's entirely possible that my library customizations caused the corruption issue but not something I'm going to spend time trying to figure out.

[kovidgoyal]

calibre is designed to load all the book entries from the database directly into RAM, at startup. This allows for features such as the Tag browser, advanced searching (regular expressions, comparisons), etc, to both be easily implemented and fast in operation, not requiring disk access for any post startup operations.

A more typical CRUD app would not bother, it would just limit itself to whatever the database engine allowed. That is the source of calibre's "slow startup time". For something like citadel which aspires to be just a dumb, do nothing listicle app, delegating to the database will be more than sufficient, and it will naturally startup faster, since it queries the db just for enough books to populate its initial screen, especially for larger libraries as calibre startup time is basically linear in the number of entries in its db.

And yes, as someone that's dedicated almost 20 years of his life to making ebooks useable and available to all of humanity, for free, I do find things like this rather offensive/off putting. Anyone is free to make their own ebook application, but marketing it as a replacement for calibre while leeching off all the hard work that's gone into calibre is pretty damn offensive. There have been several of these over the years, that have all eventually disappeared without a trace so I just ignore them.

[wold]

Can't add much except on the GUI: for Qt apps like Calibre, loading the Qt libraries and rendering the GUI also takes its time. Though that too is becoming negligible on modern SSD systems. One of my Qt apps, if cached, is oft ready at 150ms, but the UI still takes over a second. Fast enough.

Some factors are hard limits, or not under a developers control. Or can't be easily changed or optimized. Aside, and if wanting to be mean, one could argue the Citadel UI (Svelte) is web based, requiring a browser, an even more complex beast

[Quoth]

QT apps are a negligible overhead on an HDD. Though it can depend on what is the programming language.

From Wikipedia

Qt supports various C++ compilers, including the GCC and Clang C++ compilers and the Visual Studio suite. It supports other languages with bindings or extensions, such as Python via Python bindings[15] and PHP via an extension for PHP5,[16] and has extensive internationalization support. Qt also provides Qt Quick, that includes a declarative scripting language called QML that allows using JavaScript to provide the logic. With Qt Quick, rapid application development for mobile devices became possible, while logic can still be written with native code as well to achieve the best possible performance.

When I was using QT, about the time that Nokia bought Trolltec, it was C++ only and ran faster than Java on PC or ARM Linux Tablet.

Edit:

Originally Posted by wold

Aside, and if wanting to be mean, one could argue the Citadel UI (Svelte) is web based, requiring a browser, an even more complex beast

A browser engine only makes sense either for Internet content, or an ebook viewer. It never makes sense for a stanalone local application.

If someone wants to do an alternative to Calibre they shouldn't be using Calibre database. Also if they want true multiuser it could then use a browser and a server/service process (and Apache etc with PHP is a lazy route) with MariaDB, MSDE, MSSQL or MySQl etc, that can run locally or remotely. Though a combo client with the browser engine only used for a viewer is far better. Years ago I ran MySQL, PHP and Apache on Windows 2000.

[rantanplan]

Depending on the database of another tool is just asking for trouble. Whenever Kovid makes changes to the table structures, it'll fuck up your library. And a lot of people probably don't do regular backups. I forget about backups, half the time.

Calibre isn't that complicated, either. It has a lot of buttons and dropdowns, but if you just keep in mind what you want to achieve with it, and use the comprehensive online-help, you'll always get Calibre to do what you want it to do. And if I can't figure it out, mobileread forums will help me do it.

Also, if you need a streamlined tool that is multi-user compatible, just use Calibre-web. At least it's mature and doesn't crash. Come to think of it, what are the advantages of Citadel if we already have Calibre-web?

[Quoth]

Part of the apparent complexity is the ability for conversions, searches, metadata, different kinds of ereaders and different formats.

what are the advantages of Citadel if we already have Calibre-web?

Probably none, but I don't use Calibre Web.

[mbovenka]

Originally Posted by gbm

The fact that calibre opens in 1.64 seconds with 3719 books and is sable makes me wonder how it could be faster. if I was using a cpu with pci4 or 5 bus and NVMe SSD sure it would be faster.

Not by much. That would only speed up the reading of metadata.db from disk, and that's not where most of the startup time is; it's in the creation of the in-memory DB image from it once it's read into memory.

Calibre benefits from a fast CPU, and as parts of it are single-threaded, from single-core performance.

[Quoth]

Servers benefit most from multicore. Or parallelised simulations. With single user single application a single core performance is most important, assuming there is no off-device communication and only 2D rendering in one window at a time. Most improvement with 2 to 4 and at 4 the I/O is the bottle-neck. Anyone know how an Android tablet (which usually has only one window) with no Cell/wifi/BT/audio running can possibly need 8 cores and how many can it realistically use with more than 10% performance increase than 2 or 4?

Sometimes I wonder would a 2 core CPU with massive RAM on chip instead of cache and GPU on chip be better than 8 core for a single user regular laptop/phone/tablet/ereader.