Your library.
> powerful applications to navigate them (Total Commander / mc / Krusader).
Not powerful enough. Filemanagers are optimized for hierachical views and don't integrate well with filetypes. Namely, they usually don't extract data from files, like metadata, covers or previews. Though, filemanagers have started to do that to some degree.
But they still lack the "alternate view" on your library. Those Walled Garden-Apps that work with librarys are more like a relational database, offering flexible selections and content-optimized views that filemanagers are normally lacking.
The major difference is really just if you want a static and inflexible organization, or something dynamic. And usually with heterogeneous datas, the dynamic approach is better for consuming beacuse it allows you to break through the hierachy.
> (eg. where do I find all those books when I want to copy them?). > I hate Calibre for the exact same reason.
Just select your books and export them. Calibre can export to a device, but also just a local directory. Calibre in that regard is one of the better gardens. Very flexible and powerful. Just the UI sucks.
The UI can be improved quite a bit, check out icon packs like this one: https://github.com/PapirusDevelopmentTeam/papirus-calibre-th...
For me, that looks pretty good, comparable to qBitorrent or 7zip.
Calibres menus, configuration and the general flow is very messy. Partly because calibre is doing so many different things, but partly also because it's just very unpolished.
Thankfully, there are also full-text indexers like spotlight and tracker.
The advantage of integrated solutions is that you have less work to replicate your workspace on a new device, often even no work at all. How well does that work with indexer? Spotlight does not even work indepedant of the platform, tracker is Gnome-ware, does it integrate with KDE or Non-KDE?
> Your library.
Yes, its already there and quite organized in directories. Now ebook readers came along and pressed those hierarchical data flat, with long waiting times, because it needs to index first.
>> powerful applications to navigate them (Total Commander / mc / Krusader).
> Not powerful enough. Filemanagers are optimized for hierachical views and don't integrate well with filetypes. Namely, they usually don't extract data from files, like metadata, covers or previews. Though, filemanagers have started to do that to some degree.
grep and find works quite well for most work loads and are fast, why not enhance (or fork) them to support ebook formats?
Instead ebook readers came along and reinvented filesystems, because users cannot be trusted to organize their book collection themselves.
> But they still lack the "alternate view" on your library. Those Walled Garden-Apps that work with librarys are more like a relational database, offering flexible selections and content-optimized views that filemanagers are normally lacking.
And at the same time omit very useful information that normal file managers show. (File creation/write/access time, size, full file name, etc.)
> The major difference is really just if you want a static and inflexible organization, or something dynamic. And usually with heterogeneous datas, the dynamic approach is better for consuming beacuse it allows you to break through the hierachy.
As I said, with long indexing times. I had ~50000 books on a ebook reader once and that broke it. Just because there are files stored, that should not slow down the system or even make it completely unusable.
Instead they should just access the filesystem directly, then those problems don't even arise.
>> (eg. where do I find all those books when I want to copy them?). > I hate Calibre for the exact same reason.
> Just select your books and export them. Calibre can export to a device, but also just a local directory. Calibre in that regard is one of the better gardens. Very flexible and powerful. Just the UI sucks.
Calibre is a pretty big application and they are not an ebook reader primarily. Their main feature is the library. And they spend many man years of development to improve that and it does work quite well.
But very few ebook applications and handheld readers have the same resources to implement a similarly powerful library functionality. Instead they have half backed solutions that make finding and organizing the library more difficult then if they would have simply used a standard file manager and grep/find/...
IMO an application that lets you just open epubs and other ebook formats and render them correctly just like so many pdf viewer do, without any half assed library functionality duck taped on to it, is highly sought after.
In the early days of Mac OSX, iTunes actually did a great job of just organizing your music collection for you. It would sort your music into a nested hierarchy by artist, album, and track title based on the metadata on the file, which you could edit with iTunes. When you changed stuff around it would actually modify where the files were saved in the library folder.
It worked great. It was structured logically in your iTunes library, but organizing and tagging your iTunes library also wound up structuring your file system logically automatically. So there was never this sense of a pretty veneer over a messy clusterfuck underneath. The whole thing is designed to keep things tidy and organized.
So you do understand the general concept of a library. Then you also understand the limitations of directories and how much work goes in maintaining this system.
> Now ebook readers came along and pressed those hierarchical data flat, with long waiting times, because it needs to index first.
I don't think Ebook-readers started this. ITunes had this first I think, or whatever app ITunes copied from back then.
> grep and find works quite well for most work loads and are fast, why not enhance (or fork) them to support ebook formats?
Doesn't solve the problem. Grep and find don't give a useful interface for elaborated tasks. They also don't support metadata which are not supported by a fileformat, meaning "external" metadata.
> And at the same time omit very useful information that normal file managers show. (File creation/write/access time, size, full file name, etc.)
Depends on the application, and the user. Not all of those information are useful for everyone. Calibre for example has good support for filemanagers. Each entry has a link to open the folder with the ebooks. The whole library is saved as a folder-hierachy with metadate extrated into seperate files. The Database-View is just an additional layer.
> As I said, with long indexing times. I had ~50000 books on a ebook reader once and that broke it. Just because there are files stored, that should not slow down the system or even make it completely unusable.
Indexing is a neccessary tradeoff for gaining power. The alternative would be to constantly scan all files, making every single task slower. grep and find have their price too.
> But very few ebook applications and handheld readers have the same resources to implement a similarly powerful library functionality. Instead they have half backed solutions that make finding and organizing the library more difficult then if they would have simply used a standard file manager and grep/find/...
Oh yeah, I guess grep on an eReader would be a real pleasure to use...
> IMO an application that lets you just open epubs and other ebook formats and render them correctly just like so many pdf viewer do, without any half assed library functionality duck taped on to it, is highly sought after.
Those applications exist. Calibre even comes with one out of the box. Not their fault if you just start the library and not the reader.
I am not against an index or library in addition to the file hierarchy, but I am against a library or index replacing a directory listing.
Both perspectives are very valuable!
Also a full text search (grep) or (more or less simple) file search (find) are useful in addition to a library.
To reiterate, for me it seems that itunes and ebook reader generation of devices and applications don't seem to value custom directory organization.
> Those applications exist. Calibre even comes with one out of the box. Not their fault if you just start the library and not the reader.
While the library part of calibre is very good, the reader part is not so great, but that just might be because a library application is much more difficult to implement than the reader, so bad UI can be looked over there, but not in the reader. Otherwise I agree that this the application of choice for reading ebooks on Linux desktop.
I have at least two dimensions I'm dealing with: title, and file type. Really though, it's nice to also organize by genre, and year.
I also dislike most of these walled garden library apps, and they are usually poorly written and obtuse. I would love an app that can scan my existing ebook repo, and then also create an index database, and make the books available on my mobile device.
One pattern for sharing my rigidly structured data from my desktop to my iPad, is to just share my working tree over Dropbox, because I use git-annex for my file collections. That way, I have automatic syncing of the files, but also the safety of snapshots. If I do want to incorporate a change I make on a mobile device, I can simply make a commit on my desktop, but if some poorly written app decides to start screwing with my metadata, I can re-check the files out. OSX Preview.app is infamous for this.
And scripts that 'index' the books and create a directory structure of the metadata (like tags, series, publication date etc.) containing symlinks to the real books.
Do you primarily or only use one computer or one os?
I'm on 3 different OSes regularly, over 5 different computers counting ones at work. For me, the effort to setup custom directory organization is a complete waste of time unless structure and tags can easily travel between computers, filesystems, and OSes.
Letting the app (Calibre for books, Mendeley Desktop for pdf's) organize however it wants lets me just clone the directory and preserve tags, which is actually what is important to me (or in the case of Mendeley, log in and sync documents/tags). I'm not a music listener at work or I'd just let an app organize that too if it syncs my tags.
They can -- they're just files.
Yes, because it's expensive and has little value for the user. A guided application, streamlinend for well defined purpose is always simpler to create and cheaper to maintain. There is a reason why free software is usually more open for user-custimization.
> While the library part of calibre is very good, the reader part is not so great
Indeed. I thinks it's mainly because calibre is mostly used for feeding devices and maintaining and manipulating the library, less for actual reading books on desktop-PCs.
Fbreader lets me browse the filesystem, or search by different metadata.
>> Your library.
> Yes, its already there and quite organized in directories. Now ebook readers came along and pressed those hierarchical data flat, with long waiting times, because it needs to index first.
This has been a complaint of mine with music programs for, literally I think, decades. If you need to overlay some metadata that's fine, but in that case at least index it by header checksums or something, not by file names and paths! (Especially not absolute paths.) Please respect my organizational choices and make sure I can rename and move things around without worrying about "ruining" the database.
How are you going to play music you've added in the last three years, but not heard for a month, from the "Latin" genre, with two or more stars, using only the file system? With an iTunes smart playlist, it's trivial.
In Calibre it's trivial to sort the books by Title, Author, or (my self-defined and filled) Genre column.
How would you even start to manage photos in the file system? By name?
honest question: why would you ever like to do that?
I find calibre unusable because of these things. I just have one epub file and I want to read it. However, the damn program forces me to "initialize my library" and other bullshit.
Photos is actually an exception for me due to the personal nature of them. I group them in directories based on date ranges and events. I don't want to upload them to some webapp or cloud storage for privacy reasons.
BeOS actually solved this 20 years ago with its file system BFS. Haiku is an open source reimplementation of BeOS that recently progressed from (high quality) alpha releases to its first beta.
I think that the problem is that a file system typically represents a single type of hierarchy. Maybe you have your books in the file system arranged by topic->author->book, but other arrangements like topic->year->book, book->year (for editions) or author->book->author->book->... (for citations) can be useful. Maybe you want to list books that relate to a set of multiple topics written by either of two specific authors.
In Unix you can solve this by using symbolic links, which may become tedious to maintain (but less so by using automated tools). Generally, you can sort of address it by including meta information in the file names (like the warez scene does), but that is tedious when you have a lot of potentially relevant meta information.
The benefits of throwing all the information into a relational database and querying into that instead of a regular PC file system is that you can define the desired hierarchy and what meta-data is important on the fly and effectively create a file system (in the pre-computer sense) and perform a search at the same time.
I haven't looked closely enough at this software to say that its "library" actually addresses these concerns, but for large libraries there are obvious benefits to 1) Using multiple hierarchies or faceted classification for information query 2) defining such hierarchies or sets of classifying categories on the fly. These aren't new solutions, and fundamentally the organization of information in a library is not a new problem, so I wouldn't call your position old school.
If by "this context" you mean exactly the use case you describe, then yes. If you are always looking for books you already know of and can name, there is little point in further classification.
Another potential use case is that I have tens of thousands of books and I am looking for English-language fictional books about scientists and monsters by authors born in the 18th century.
Again, I haven't looked closely at the app and chances are that it doesn't really help in that use case either, but I meant to explain the concept of a "library" to someone who did not understand it, and why a simple hierarchical file system may be an insufficient abstraction for library classification in general.
I hate library/playlist oriented stuff. I have everything organized in folders and files, with good filenames. Since I have in my collection a lot of unkown, old or rare media, most programs are not able to find out what it it or even tag them wrong!
I still use foobar. On my kodi setup, I navigate almost everything via file browser. I spent a lot of time finding a decent folder oriented audio player for android.
You're right that this often causes problems. Anybody who has tried to salvage an iTunes library can attest to that.
However you're downplaying the positives to having a metadata database, and you're also ignoring the teeming masses who don't care about the layout of the file system as long as it's displayed in the app.
Same thing with pdf's - I used to keep a bunch of docs in my own subdir, until it got to be 1000+ pdf's and I discovered Mendeley Desktop and its tagging feature. Now I can find stuff much faster.
Same thing with my music collection, same thing my with photos.
Your needs may be minimal enough and your computer skills sufficient enough so that you get by with the filesystem, but I would venture to say the average user is much better off with an app/library method of organization. e.g., I can't fathom organizing a non-trivial photo collection via the filesystem only. I know I'm better off with the app/library method of organizing data, something I came to realize after my initial resistance.
We have uses with over 30,000 eBooks in their libraries and will be able to support your collection without issues. BookFusion allows you to easily upload, read and organize(tags and categories) your eBooks.
Your entire Calibre eBook collection will be available across all your devices while keeping your bookmarks, comments, highlights and reading progress synced.
More at https://www.bookfusion.com/reading/cloud-library
We even have a Calibre plugin that will allow you to easily sync your entire collection or only eBooks you are interested in.
https://www.bookfusion.com/reading/calibre
PS: I am the founder of BookFusion
My mother in law knows that, conceptually and practically, when she taps the Kindle icon on her tablet she will open her collection of books. Within that full-screen app, she is intending to do one of several things: find a book to read, then read that book.
She doesn't really like the filesystem on her imac. She much prefers that all the files associated with a given activity are readily available when she is doing that particular activity. Gallery -> Photos. Library -> Kindle. TV Shows -> Netflix. She doesn't really think about how each of those search and organization functions act differently between apps.
We all do the same, to a great or lesser degree. Orgzly has my org-mode files right there. Microsoft RDP client beta has a group of all the RDP sessions I use right there. Outlook has all emails and calendar items.
I absolutely suffer when my filesystem is chaotic, which it often is: but then again so is my job, doing systems admin, devops, code builds, puppet/ansible/chef stuff, etc etc. Being able to quickly find things in a freeform manner is very, very useful. (I use 'fzf' and zsh for commands and directories, and 'mdfind' (on mac) for its faster-than-grep file search)
Essentially, the library system and the traditional filesystem are the same, to the extent that they both filter and group files by a select group of criteria. In the case of the filesystem, the criteria are file path, sizes, date added, etc. In the case of a library system, the criteria are specific types metadata that are meaningful for the type of media it manages (genres and artists for music, publishers and categories for books, etc.). Their features do intersect, and you can have both worlds in one system with some hacks, but the convenience and design also matter.
For me, I read ebooks but don’t hoard them, so I don’t need Calibre to manage my petite amount of epubs -- folders and filenames are enough. But I do listen to a lot of music, so I can’t manage efficiently without a music library software like iTunes. A person who is a voracious reader but rare listener, however, may have a choice just opposite to mine, which is also completely reasonable.
I'm not even sure where to start. But that you can't even envision a few reasons why someone would use something is very limiting. At least on an empathy level but probably on a professional product-design level as well.
I can certainly appreciate your point when the software's backing database is unusable and human-unfriendly, and this is supposedly the reason why you hate Calibre, but the folder that Calibre stores my 12k books in and it's nicely organized. The other day I even Airdropped it to my friend where he imported it into macOS' Books.app.
With that said, I would be happy if you could take BookFusion for a spin and let me know if you have any feedback. Our users have libraries with over 30,000 eBooks and as a result we will have no issues with your collection.
BookFusion allows you to easily upload, organize and read all your eBooks regardless of format on iOS, Android and Web enabled devices.
More at https://www.bookfusion.com/reading/cloud-library
BookFusion also has a Calibre plugin that will allow you to easily sync your eBook collection. https://www.bookfusion.com/reading/calibre
PS: I am the founder of BookFusion and would be happy to hear any feedback that you might have
Unfortunately, I could not find anywhere on your site that indicated the cost associated with an individual user account. (Free to signup, of course, but how long is that trial, or what limits will I face? and then how much money will this subscription service cost me?)
End-users have serious account fatigue, and I seriously debated whether I should bother signing up for the site and create yet another login to a web app I might or might not want to use. Please, just be up front about pricing, free trials, limitations, requirements, etc.
If you have a 7-day free trial and I'm currently busy, I won't have time to kick the wheels before I'd need to pay. If you instead limit the number of books or the storage space I can use, just tell me so I can decide if it's worth bothering to test it out. As far as I can tell, you might or might not have a limit for a new/free user, but no idea what that is.
Finally, I see in the settings that you offer an early bird subscriber deal, at $4.99/mo (vs $9.99/mo) and $39.99/yr (vs $60/yr), for unlimited storage. I think you might have better luck with a tiered setup. Someone with a lot of ebooks might find $40/year to be a great deal, but most users likely don't have that large of a collection - they're looking for more of an ease of use and convenience factor. Take advantage of that, and then allow them to move up and give you more money once their collection grows.
$10/year = 4GB storage or 2000 ebooks? (count # of books, and not storage, to make it seem less technical?) $20/year = 8GB storage or 4000 ebooks? $40/year = 20GB storage or __? $60/year = unlimited
or $10/$30/$60 year, with 2000/10,000/unlimited? and only allow monthly payment as an option for the $30/$60 levels?
at $10/year, it would be an impulse buy for most readers, and then you not only have a paying relationship with them right away, you have a whole year to demonstrate the ease of use and utility of the product.
Calibre doesn't obfuscate / embed the book files. They copy under a folder with Author's name. You can pretty easily access the original file pretty quickly. Maybe you can configure Calibre to use your directory structure without modifying it.
BTW, I don't understand the use case of reading ebooks on a desktop or laptop instead of on a phone or tablet (or eink reader.) Is this really common? I can imagine reading some technical ebook at my computer while working at my desk, but not fiction or anything else.
Unfortunately, not everyone has all the screens, and not all phone screens are big enough to read novels and such. I'd rather read a book in my bed on my laptop screen and take notes quickly rather than an older phone and try to write on its keyboard.
Also, e-ink readers' screen refresh rate prevents taking extensive notes on the books. You can underline just fine, but longer notes are a bit hard.
Last but not the least, comic books in CBZ/CBR format really begs for a quality color display, since colored comics is half the fun in the comics. :D
When your collection grows though, issues start to show up. Being able to sort, and find a book based on other information becomes much more useful: date of publication, genre, custom tags, etc... While you could always integrate these in your filename/directory structure, with the help of symlinks, it's very cumbersome to manage and use.
Yes, and I want to be able to do that with all my books, not just the ones that the ebook reader can handle.
Maybe if you just dump a large number of unsorted files in place and do nothing with them. With a decent file manager and an hour or so, you can add many books and symlink them to the metadata directory with no issue.
Alternatively you can use a program's built-in library with no time cost to yourself...
An hour? You've made my case. It takes at most a couple of minutes for importing hundreds of books in Calibre. Metadata retrieval is automatic (from the file itself and/or online). Everything happens in a few clicks.
It's very similar to Bookworm in this regard.
The main reason we do it is repository integrity.
We can replicate it easily with the cloud and enable real time collaboration.
You can also keep the files on disk if you want and in their original directories as we use a hard link.
What directory would I put my copy of Stephen King's It in? My Stephen King folder? My horror folder? 1986? Fiction?
The underlying file system view really doesn't matter. It's the abstraction on top of that where all the interesting things happen.
I suppose that the "library" model is what most people prefer since most modern media apps use that in some form or another. Or maybe it is because of Steve Jobs reality distortion field ( https://oleb.net/blog/2012/06/steve-jobs-on-the-file-system/ ). Still, I hate all these apps attempting to hide the filesystem from me.
I'm sure there's a "dropbox is just rsync" type answer, but this is for regular users
No, come on, be fair, let's replicate the capabilities of the file system: You can sort them both by ISBN and by size.
I just move around my file system like normal and then open them in light weight readers like Zathura. Browsing is the same as any other directory, the files open immediately, it works offline and it's easy to sync between devices.
I apply this same strategy to MP3s too.
A filesystem is perfectly fine, if used correctly, for the average ebook reader use-case.
If you have 10 million ebooks and need to run 100 complex searches per second then you need an RDBMS.
Why would an ebook reader even try to do the navigation for me? It should display an ebook, and I'll take care of the rest.
If it's showing me the file system, it's redundant. If it's showing me the "library" according to its own logic, then it breaks the consistency. And it makes my life so much harder (eg. where do I find all those books when I want to copy them?).
I hate Calibre for the exact same reason.