The tools are meant for those who live on the command line, this more or less excludes 'non-technical people'. For those non-technical people there is always the multitude of web things, the Windows tool which started this thread and the plain ol' Library, the which the Library Genesis project - that is, the original version as headed by Bookwarrior - aims/aimed to be.
Let there always be tools tailored to specific group's needs, the one-size-fits-all approach nearly always ends up dumbing down the interface by removing 'difficult to use' functions and 'complicated' options to present a Fisher-prize interface with big happy buttons and lots of open space.
Also notice that the Books tools weigh in at 47K compressed, there is something to be said for light and nimble tools.
Alexandria [1] is pretty much a UI-based Mac app version of Books. I've been maintaining it for a while now and whenever I share it with someone non-technical Libgen's breadth blows their mind.
Linux support should be extremely simple to test and deploy. It'd be like an hour's task to write up a github action for it so you don't even need to have a local linux deploy or whatever.
I was going to do it myself but the build scripts you made are incompatible with node 17.x.x (it requires exporting `NODE_OPTIONS=--openssl-legacy-provider`), and they also seem to assume that `react-scripts`, etc. are in the local environment, rather than including them portably as a yarn package dependency and then doing `yarn exec <xyz>`. There's too much weirdness here and I'm not familiar enough with the systems involved to even begin looking into making it compatible (I started, and then realised that I'm supposed to be relaxing from my fulltime job, not dealing with more weird new tech systems that don't behave sensibly).
"This fence is so long and sprawling that even thinking about painting it negatively affects my health. But I bet you could knock it out in under an hour," Tom said to the other children.
Later that afternoon, Aunt Polly arrived home to an unpainted fence.
I don't think it's a stretch to say that the primary maintainer, the person who wrote the (extremely slapdash) build scripts and knows exactly why it's copying folders during the build process, is going to get the changes done faster than someone who is not knowledgeable with the tools and codebase? Writing code isn't painting fences, it's like asking me to replace a set of levers on an industrial piping system, except at least then the specifications of the prior levers would be available and there would be documentation for the whole thing.
The way this works is that if you're in a highly competitive market where all the products are equally capable and one of them is at all easier to use, that one wins. Then people get the impression that everyone is a dunce because the slightest inconvenience causes them to give up and use something else.
But then you come to something where there is only one way to do that thing, or the competition has some countervailing disadvantage, and suddenly Bob from accounts knows how to use AS/400.
Whilst I appreciate the sentiment, most plans based on the premise that "all the children are above average" can be true will fail.
The Internet, WWW, and Google were once power-user tools. Global education has increased only modestly. The biggest change has been in lowering barriers to ease of use, including but not limited to the cost of tools.
This isn't an unalloyed blessing --- the minimum viable user is both a blessing and curse:
